fix(core): unref the CDP deadline so it can't delay process exit by rishigupta1599 · Pull Request #2405 · percy/cli

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.

rishigupta1599 · 2026-08-27T09:58:06Z

Summary

Follow-up to the CDP send deadline. The deadline is a watchdog, but its timer was not unref'd, so it holds the Node event loop open.

An orphaned send — one whose reply is never coming — leaves that timer live for the full deadline. This is not exotic: it happens routinely when a page closes with a Fetch.continueResponse still in flight. By then the real work is done, so the CLI sits idle for up to two minutes after printing Finalized build #… before exiting.

I hit this intermittently (once in four runs) while capturing a real Storybook: the run went quiet after finalizing and exited 116s later, exactly when the deadline fired.

[percy:core] Finalized build #10544: https://percy.io/…
[percy:client] Sending Build Events
[percy:core:session] Protocol timeout (Fetch.continueResponse) after 120000ms (116197ms) <- 116s of idling

A watchdog should never be the reason a process cannot exit. unref() matches the existing precedent in server.js, and the timer still fires normally whenever anything else is keeping the loop alive — which is the case for every send that matters.

Test plan

Two new specs (one per send path) capture the created timer and assert hasRef() === false, so a future change that re-refs the watchdog fails the suite.
All 13 specs in packages/core/test/unit/session.test.js pass; eslint clean.
Verified in a real process with a probe holding one orphaned send at a 30s deadline:
process exit
unref'd (this PR) 346ms
ref'd (before) 30162ms

Notes

Deliberately unguarded .unref() rather than .unref?.(): server.js:226 already does the same, and an optional call would add a branch whose false arm is unreachable in Node, breaking the 100% branch-coverage gate.
The new spec helper swaps global.setTimeout to capture the deadline, and hands the real setTimeout to the callback so its own waits aren't captured — otherwise there's no telling which timer is which.

🤖 Generated with Claude Code

The deadline added for stalled-browser recovery is a watchdog, but it was holding the event loop open. An orphaned send - one whose reply is never coming, which happens routinely when a page closes with a Fetch.continueResponse still in flight - keeps a live timer for the full deadline. The work is already finished at that point, so the CLI sits idle for up to two minutes after printing "Finalized build" before exiting. Observed intermittently (once in four runs) on a real storybook capture: the run went quiet after finalizing and exited 116s later, when the deadline fired. Unref matches the existing precedent in server.js, and the timer still fires normally while anything else keeps the loop alive. Verified with a probe process holding one orphaned send at a 30s deadline: exits in 346ms unref'd, 30162ms ref'd.