Adversarial re-review of c197b2c found the previous fix both incomplete AND that it
introduced a new stuck-state regression. Two independent reviewers flagged the latter.
HIGH (data loss, still open after the last fix) — a worker could claim a LIVE seq
after a reopen. `claim_job` took any `pending` row. If a reopen landed between
`release_gallery`'s spawn and the worker's claim, the row was left pending at the
*bumped* seq, so the worker claimed a CURRENT generation and spent minutes exporting a
snapshot taken while the event was open and guests were still uploading. On the next
re-release (which re-arms `export_released_at` BEFORE it bumps the seq) that worker's
finalize and ready-flip both passed their guards, flipped ready on its stale snapshot,
and made `enqueue_and_spawn_exports` skip regeneration — silently serving a keepsake
missing every upload from the reopen window. The reopen seq-bump did not help: the
worker's seq was not stale.
Fix: `claim_job` now refuses to claim unless the event is still released. A worker's
generation is therefore always born AND finalized inside a single live release epoch.
The unclaimed pending row is harmless — the next release resets and re-spawns it.
HIGH (regression I introduced in c197b2c) — `open_event`'s event-UPDATE and its
export_job seq-bump were two autocommit statements. The first is exactly what re-enables
`release_gallery`, so a re-release could slip between them: it spawns a FRESH worker at
seq N+1, then our second statement bumps that live generation to N+2, orphaning the
worker. Its seq-guarded finalize/fail/flip then all match nothing, the row is stranded
`running` with no owner, and the host cannot retry ("bereits freigegeben") — only a
process restart recovers it.
Fix: both statements now run in one transaction, so the row lock on `event` serializes
`release_gallery` behind the commit.
LOW
- The flip-lost path left its stale archive on disk (asymmetric with the finalize-lost
path, which deletes it). If a host reopened and never re-released, no future
generation would ever prune it. Now discards `out_path` and still sweeps older gens.
- A reopen clears the ready flags server-side, but nothing told the clients: the nav and
/export page kept advertising a keepsake that now 404s. Both now refresh on
`event-opened` (a superseded worker deliberately emits no `export-progress`).
Tests
- New: a release broadcasts `export-progress` 100 for both types + one `export-available`.
The export SSE had ZERO e2e coverage, and this round made the emit conditional —
`/export/status` polling reads the job row, not the SSE, so a regression here would
have left every other test green while the live UI silently stopped updating.
- New: open ‖ release churn always converges to a consistent, downloadable keepsake.
Honestly labelled a STRESS test, not a regression guard: verified it still passes
against a deliberately non-transactional build even with ~90 concurrent pairs, so it
does NOT cover the atomicity fix (that window is not reproducible out-of-process).
- Verified the reopen-supersession test is non-vacuous by empirically reverting the
seq-bump — it fails, as intended.
Verified: backend 40 tests, svelte-check 0 errors, e2e typecheck clean,
e2e 158 passed / 1 skipped on chromium-desktop.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
9f3712894d