fix: terminate signal-owned publication process trees - #625
fix: terminate signal-owned publication process trees#625mldangelo-oai wants to merge 4 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex review |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
kmbroai
left a comment
There was a problem hiding this comment.
Critical review
Reviewed head ae7b2d70a06502459c939e47c54d0e619a266360 against its declared stacked base, #624.
Recommendation: keep this fix; no new merge-blocking defect found in the reviewed changes. The necessary behavior is narrow: a second cancellation signal must terminate the publisher's process tree before the CLI exits. Otherwise the CLI can disappear while a connected publisher continues doing externally visible work. Applying escalation to connected publication as well as direct-API publication is warranted.
Correctness
The ownership boundary in runPublicationCodex is appropriate: only children with an explicit abort signal are registered and detached on POSIX. Ordinary signal-less SDK children remain attached to their caller. Cleanup removes both the registration and abort listener, and cancellation's final process-group kill handles descendants that outlive the direct child. In the CLI, force termination happens before signal handlers are removed and the injected exit runs; it does not merely schedule work that process exit would discard.
Necessity and simplification
Keep this as a cancellation/ownership patch rather than expanding it into a generic subprocess supervisor. A small registry is justified because final CLI exit cannot await a per-call cancellation promise. The shared process-group helper is already reused. The Windows synchronous and asynchronous taskkill paths have different lifecycle requirements, so combining them just to remove a few lines would obscure the reason for the synchronous path.
The same-signal delivery debounce and ordinary SDK ownership tests are useful counterexamples: “kill everything on every signal” would be a regression. Preserve those contracts when rebasing on the large #624 publication changes; passing this child PR does not independently validate all of that base's recovery logic.
Verification
Ran the checked-in publication-integration.test.ts and publish.test.ts: 76 passed, 0 failed on Linux, Bun 1.3.14 / Node 22.13.1 with cached dependencies. This includes actual descendant-process cancellation and the injected Windows taskkill command check. It was not a native Windows run, a clean dependency installation, or a live Linear publication.
faizan-oai
left a comment
There was a problem hiding this comment.
Reviewed this PR's delta against #624, including signal-owned process-tree termination and no-signal SDK behavior. Focused tests and current-head CI pass. No blocking findings in this delta; the stack's merge order remains separate.
Summary
When a connected publication ignored cooperative cancellation, a later terminal signal could exit the CLI without first stopping the publication process tree. This change gives the CLI a synchronous forced-exit path for signal-owned publication processes while preserving recovery evidence and caller ownership for SDK publications without a signal.
This pull request is stacked on #624.
Changes
taskkill /PID ... /T /Ffor the equivalent tree operation.Testing
1356491567.1917048208.753168830.umask 077: 1,700 passed, 28 expected skips, 0 failed, 22,308 assertions, seed3195823917.pnpm run types,pnpm run format, andgit diff --check: passed.gpt-5.6-solreviews at maximum reasoning on exact headae7b2d70a06502459c939e47c54d0e619a266360: no actionable correctness findings.Risk and rollout
The force helper remains internal to the publication module and is not exported from the package root. No public command or SDK option changes. POSIX tests assert the exact negative-process-group
SIGKILL; Windows tests assert the exact synchronoustaskkillexecutable and arguments, with hosted Windows CI providing the native platform gate. Iftaskkillitself fails, the existing direct-child fallback remains best effort.Public disclosure review