A step that runs without a cell ends with everything it started, on a cancel, a timeout, or its own exit #64
No reviewers
Labels
No labels
agent-work
agent-working
ultracode
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
trevato-apps/forge!64
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "grokbot/forge:fix/step-stop-whole-tree"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Where the host cannot hold a cell (CI, a pod without bwrap), an install,
test or check step ran as a plain
/bin/sh -cchild in the forge's ownprocess group, and a cancel or timeout SIGKILLed the shell alone. What
the shell had started (
bun install's scripts, a test runner and itsworkers, a
sleep) was re-parented and kept running in the checkoutafter the step was reported cancelled; a superseded check kept burning
the machine beside its replacement.
The step now leads a process group of its own (
detached, without acell only), a cancel or timeout kills the group, and once the shell has
exited, what is left of the group is killed. A cell is unchanged: its
tree dies with bubblewrap.
signalGroupmoves to module level, sharedwith
startProcess(#63).Since a terminal's Ctrl-C no longer reaches a running check, the forge
stops checks without the roll's drain wait on a person's signal
(SIGINT, SIGHUP): they are cut off and queued again at once. A SIGTERM
(a release) still lets them finish within FORGE_CHECKS_DRAIN_S.
Validation
pipeline/validateon82c7d253: baseline in 618s — bun 1.3.14, CI-shaped env (scrubbed vars, runner PATH), exact check.yml shard + forge.json commands.bun install --frozen-lockfileforge.json check.fastcheck.yml gate (1) pull_requestcheck.yml gate (2) pull_requestcheck.yml gate (3) pull_requesttest output (failures, totals)