Problem
On Windows, terminateChild reserves 2.0s for the graceful taskkill /T phase but only 0.5s for the force taskkill /T /F phase (0.4s after the helper-close reserve). On this host, force taskkill frequently needs more than that. The manager reaches the fail-closed unresolved path before the tree-kill helper can report success, so a real descendant-tree termination is reported as failed.
This is not the timeout false-success bug fixed by #412 (which intentionally preserves unresolved once a helper times out), nor #592's post-signal child-lifecycle handling. The remaining issue is the Windows phase-budget allocation within the same fixed 2.5s termination window.
Reproduction
- Baseline:
origin/main at 43cd2e94cc584f81cc1f27512ae99c9a4099b231.
- Windows 11; Node
v24.14.1; Bun dependency install from the checked-in lockfile.
node --experimental-strip-types --test --test-reporter=spec --test-name-pattern="^taskkill terminates a Windows descendant process tree$" tests/extensions/background-terminals/manager.test.ts
- Actual on unchanged main: fails after about 4.95s; expected: the
taskkill /T tree-kill test reports killed and confirms the descendant is gone.
A direct measurement of this machine's taskkill /T /F ranged from about 608ms to 1223ms. The present 400ms force-helper wait is therefore too small. A combined pressure run can still be timing-sensitive, so a fix must retain the existing 2.5s overall bound and not reintroduce shell-only fallback or false success.
Proposed scope
Redistribute the existing Windows phase budgets to 1500ms graceful plus 1000ms force, leaving non-Windows behavior and the overall 2500ms termination budget unchanged. I am taking this issue and will provide the smallest focused PR with the real descendant-tree regression evidence.
Problem
On Windows,
terminateChildreserves 2.0s for the gracefultaskkill /Tphase but only 0.5s for the forcetaskkill /T /Fphase (0.4s after the helper-close reserve). On this host, force taskkill frequently needs more than that. The manager reaches the fail-closed unresolved path before the tree-kill helper can report success, so a real descendant-tree termination is reported as failed.This is not the timeout false-success bug fixed by #412 (which intentionally preserves
unresolvedonce a helper times out), nor #592's post-signal child-lifecycle handling. The remaining issue is the Windows phase-budget allocation within the same fixed 2.5s termination window.Reproduction
origin/mainat43cd2e94cc584f81cc1f27512ae99c9a4099b231.v24.14.1; Bun dependency install from the checked-in lockfile.node --experimental-strip-types --test --test-reporter=spec --test-name-pattern="^taskkill terminates a Windows descendant process tree$" tests/extensions/background-terminals/manager.test.tstaskkill /Ttree-kill test reportskilledand confirms the descendant is gone.A direct measurement of this machine's
taskkill /T /Franged from about 608ms to 1223ms. The present 400ms force-helper wait is therefore too small. A combined pressure run can still be timing-sensitive, so a fix must retain the existing 2.5s overall bound and not reintroduce shell-only fallback or false success.Proposed scope
Redistribute the existing Windows phase budgets to 1500ms graceful plus 1000ms force, leaving non-Windows behavior and the overall 2500ms termination budget unchanged. I am taking this issue and will provide the smallest focused PR with the real descendant-tree regression evidence.