Skip to content

fix(launcher): signal deaths exit 128+signal, not 0 (v1.0.1) - #46

Closed
duharry0915 wants to merge 2 commits into
mainfrom
fix/launcher-signal-exit-codes
Closed

fix(launcher): signal deaths exit 128+signal, not 0 (v1.0.1)#46
duharry0915 wants to merge 2 commits into
mainfrom
fix/launcher-signal-exit-codes

Conversation

@duharry0915

Copy link
Copy Markdown
Contributor

The npm launcher turned signal deaths into exit 0: execFileSync throws with status: null on a signal, 'status' in e was true, and process.exit(null) is exit 0. A SIGTERM'd (timeout), OOM-killed, or crashed agentmail reported success to any caller checking $?. npm path only — the direct binary returns 143 correctly.

Fix: pass numeric statuses through; on signal death exit 128+signum (TERM→143, SEGV→139), unknown→1. Verified against a stub binary:

stub before after
exit 42 42 42
SIGTERM 0 143
SIGSEGV 0 139
exit 0 0 0

Version bumped to 1.0.1 (guard-checked at tag time). Deliberately hand-patches generated ci.yml: regenerating would resurrect the deferred win32 matrix and the unfixed launcher; the generator-side fix is filed with Fern.

After merge: tag v1.0.1 to republish npm (4 platforms + launcher).

execFileSync throws with status: null when the child dies from a signal;
the launcher's 'status' in e check passed, so process.exit(null) turned
SIGTERM/SIGSEGV/OOM-kill/Ctrl-C into exit 0 — any script or agent
checking $? saw success from a killed process. npm path only; the
direct binary and installer paths were unaffected.

Now: numeric status passes through unchanged, signal deaths exit
128+signum per shell convention (SIGTERM -> 143, SIGSEGV -> 139),
unknown signals -> 1. Verified with a stub binary: 42/TERM/SEGV/0 ->
42/143/139/0.

Version -> 1.0.1 (Cargo.toml + lock) so the release tag matches the
version guard. This hand-patches generated ci.yml deliberately: a
regeneration would also resurrect the deferred win32 matrix and the
unfixed launcher, so the generator-side fix is filed with Fern and this
carries us until the next full regen.
Both publish jobs only recognized *-alpha* and *-beta*. A v1.1.0-rc.1 or
v1.0.0-next.1 tag fell through to a bare `npm publish`, which would have
moved the `latest` dist-tag to a prerelease — every `npm i -g
agentmail-cli` user upgraded onto it.

Now any identifier after the first "-" becomes the dist-tag (rc, next,
alpha, beta, ...), with build metadata stripped and a `prerelease`
fallback. Release versions still take the existing latest/backport path.
Verified:

  1.0.1            -> latest/backport path
  1.1.0-rc.1       -> --tag rc
  1.1.0-next.1     -> --tag next
  2.0.0-alpha.3    -> --tag alpha       (unchanged)
  1.0.0-beta       -> --tag beta        (unchanged)
  1.0.0+build7     -> latest/backport path
  1.0.0-rc.1+meta  -> --tag rc
  1.0.0-           -> --tag prerelease

Hand-patch on generated ci.yml, same as the launcher fix; filed with
Fern for the template.
@duharry0915

Copy link
Copy Markdown
Contributor Author

Superseded by generator 0.38.6: both patches here — the launcher signal exit codes and the prerelease dist-tag handling — are now native and verified (stub test 42/143/139/0; prerelease logic additionally handles all-numeric identifiers, which this patch did not). Adoption is in agentmail-to/agentmail-docs#214.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant