Add-host: a server that stops between commit and completion leaves an install that blocks the next add (exit 71) #376

Open
opened 2026-11-05 23:01:18 +00:00 by kayg · 0 comments
Owner

Found during the #305 round 3 end-to-end run (J241). Same family as F-B (#305) and #372.

What happens: if the server stops between the host-side commit of an add (the setup journal is deleted) and recording completion (the retirement intent is consumed), the host keeps a committed install whose .bootstrap-owner names a host the server never saw finish. The stop can be a crash or a restart during a deploy. At the next start, retire_unfinished_bootstraps revokes that host. The next add then stops at upload with exit 71, "Setup could not verify ownership or permissions of its files on this host", and offers no Start fresh. That's the dead end F-B removed for failures inside a running attempt.

Evidence: branch addhost-startfresh-j241 @ d0e84f163, compute01. The throwaway server was SIGKILLed right after the setup committed: ~claude/j241/logs/r3-leftover.txt (no journal, agent running, owner e13e710b…). Its next add: ~claude/j241/logs/r3-committed-crash.txt, server log step="upload" … exit_status=71, with the host revoked at restart.

Why F-B doesn't cover it: F-B runs in the failing attempt's own process. Here that process is gone.

Suggested direction: the check reports a committed install's owner today only as INFRATERNAL_SETUP_CLEAR. It could report it, so that the server can offer cleanup of a committed install whose owner is a host this server revoked (the same durable binding owns_failed_setup already trusts for automatic cleanup). The cleanup would use the install's own owner-scoped --bootstrap-uninstall. Needs a failing test first.

Priority: low to medium. The window is the second or so between commit and completion, but a server restart during a deploy lands in it.

Found during the #305 round 3 end-to-end run (J241). Same family as F-B (#305) and #372. **What happens:** if the server stops between the host-side commit of an add (the setup journal is deleted) and recording completion (the retirement intent is consumed), the host keeps a committed install whose `.bootstrap-owner` names a host the server never saw finish. The stop can be a crash or a restart during a deploy. At the next start, `retire_unfinished_bootstraps` revokes that host. The next add then stops at upload with exit 71, "Setup could not verify ownership or permissions of its files on this host", and offers no Start fresh. That's the dead end F-B removed for failures inside a running attempt. **Evidence:** branch `addhost-startfresh-j241` @ `d0e84f163`, compute01. The throwaway server was SIGKILLed right after the setup committed: `~claude/j241/logs/r3-leftover.txt` (no journal, agent running, owner `e13e710b…`). Its next add: `~claude/j241/logs/r3-committed-crash.txt`, server log `step="upload" … exit_status=71`, with the host revoked at restart. **Why F-B doesn't cover it:** F-B runs in the failing attempt's own process. Here that process is gone. **Suggested direction:** the check reports a committed install's owner today only as `INFRATERNAL_SETUP_CLEAR`. It could report it, so that the server can offer cleanup of a committed install whose owner is a host **this server revoked** (the same durable binding `owns_failed_setup` already trusts for automatic cleanup). The cleanup would use the install's own owner-scoped `--bootstrap-uninstall`. Needs a failing test first. **Priority:** low to medium. The window is the second or so between commit and completion, but a server restart during a deploy lands in it.
Sign in to join this conversation.
No labels
launch-qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/infraternal#376
No description provided.