Repository navigation
MANUAL RUN: check the real Alchemy stops cleanly when a deploy is interrupted (#930) #931
Closed as not planned
Description
#930 makes a stopped plan/deploy/destroy send Alchemy SIGINT, wait up to RUSTYBUNS_STOP_GRACE_MS (10s) for it to exit, then SIGKILL it. The tests use a fake Alchemy that finishes its write on SIGINT. The real one hasn't been tried.
To check, on a throwaway stage (smallest resources, destroy after):
rustybuns deploy --stage interrupt_test --yes, then Ctrl-C while it's creating resources.- Does it exit within 10s? Is
.alchemy/statereadable afterwards (arustybuns plan --stage interrupt_testthat makes sense)? - Repeat with
kill <rustybuns pid>from another terminal (SIGTERM). rustybuns destroy --stage interrupt_test.
If Alchemy needs longer than 10s to stop cleanly, raise the default grace.
Activity
fantano: install the pinned deploy set; live-interrupt.sh for #931
QuinnsCode commentedon Oct 12, 2026
Ran
packages/cli/bench/live-interrupt.sh apps/what-would-fantano-say(stageinterrupt_test, real Alchemy 2.0.0-beta.77, PR #930's CLI):destroy(Build deleted, Worker deleting): Alchemy printedExited.and stopped within the grace period. rustybuns printed✗ [Stopped] stopped by SIGINTand freed the lock. The nextdestroyread the state and finished the one remaining delete (Plan: 1 to delete, Done). The state was intact after a stop partway through a write.deploy: clean stop, no orphaned Alchemy, lock freed, and the followingplanread the state fine. But it landed while Alchemy was still loading, before it created anything, so it doesn't test SIGTERM partway through a write.DELAY=12would land it while the Worker is being created.The default 10s grace was enough. Open: one rerun with
DELAY=12.CLI: a stopped deploy stops Alchemy and frees the state lock (#930)
QuinnsCode commentedon Oct 14, 2026
Folded into the one manual-run list, section 9 of #609 (easiest first, with times). This issue's steps stay here; tick the item in #609.