Archive and Wake are each one conditional write that acts only when it moved the repository, and a Wake asked during an Archive's stop starts production after that stop #45

Merged

grokbot merged 4 commits from dev/archive-wake-atomic into main

2026-10-17 21:27:13 +00:00

grokbot commented

2026-10-17 19:22:51 +00:00

Owner

Problem. Archive and Wake were not atomic. Two Archives from the same view both stopped the app and both wrote an archived event. A Wake during a slow Archive stop did not start the app: the stop aborted the deploy that the Wake reused. The result was an awake repository with production down.

Root cause. updateRepoSettings wrote archived_at without a condition. It found the transition by a comparison with the repo it read before. The stop and the reconcile were not in order with each other.

Fix.

moveArchived in core/repos.ts is one conditional UPDATE ... WHERE archived_at IS NULL (or IS NOT NULL). It returns true only when one row changed. The action stops or reconciles only then, and writes archived in the event only then.
The core updateRepoSettings takes Omit<RepoSettings, "archived">, so it cannot write archived_at.
Each repository's transitions take one turn after another. A Wake that comes during an Archive's stop starts production after that stop.

Test. test/apps-archive-race.test.ts (real apps runtime). A Wake during an Archive's stop (a redeploy is in flight) leaves production running. Two Archives from one stale view give one archived event. On main: both fail (production failed; 2 events). With the fix: both pass. archive-web, crew and guests tests use a setArchivedIn helper on moveArchived.

Validate (fast). Result: flaky, no new failure. contain.test.ts is baseline (box DNS). tui-sentinel.test.ts failed one time in the full run. It passes alone on this branch and is not red on main. tsc passes.

**Problem.** Archive and Wake were not atomic. Two Archives from the same view both stopped the app and both wrote an `archived` event. A Wake during a slow Archive stop did not start the app: the stop aborted the deploy that the Wake reused. The result was an awake repository with production down. **Root cause.** `updateRepoSettings` wrote `archived_at` without a condition. It found the transition by a comparison with the `repo` it read before. The stop and the reconcile were not in order with each other. **Fix.** - `moveArchived` in `core/repos.ts` is one conditional `UPDATE ... WHERE archived_at IS NULL` (or `IS NOT NULL`). It returns true only when one row changed. The action stops or reconciles only then, and writes `archived` in the event only then. - The core `updateRepoSettings` takes `Omit<RepoSettings, "archived">`, so it cannot write `archived_at`. - Each repository's transitions take one turn after another. A Wake that comes during an Archive's stop starts production after that stop. **Test.** `test/apps-archive-race.test.ts` (real apps runtime). A Wake during an Archive's stop (a redeploy is in flight) leaves production running. Two Archives from one stale view give one `archived` event. On main: both fail (production `failed`; 2 events). With the fix: both pass. `archive-web`, `crew` and `guests` tests use a `setArchivedIn` helper on `moveArchived`. **Validate (fast).** Result: flaky, no new failure. `contain.test.ts` is baseline (box DNS). `tui-sentinel.test.ts` failed one time in the full run. It passes alone on this branch and is not red on main. tsc passes.

grokbot added 1 commit

2026-10-17 19:22:51 +00:00

Archive and Wake are each one conditional write that acts only when it moved the repository, and a Wake asked during an Archive's stop starts production after that stop

check / gate (2) (pull_request) Successful in 5m11s

Details

check / gate (3) (pull_request) Successful in 4m1s

Details

preview / preview (pull_request) Failing after 1m12s

Details

check / gate (1) (pull_request) Successful in 10m46s

Details

check / check (pull_request) Successful in 0s