There is no boot-time lock flush anywhere: src/server.ts ~690-770 wires SELFHOST_TRANSIENT_CACHE straight to a live Redis client with no startup purge. Every Redis-backed lock survives a container restart with its TTL intact, so #8998 (ai-review-lock, 1800s) is one instance of a general class:
| Key |
TTL |
Orphan effect |
pr-actuation-lock:<repo>#<pr> |
600s |
every close/merge/label pass for that PR defers up to 10 min |
ai-review-lock:... |
1800s |
#8998 — 30 min review starvation |
contributor-cap-wake:<repo>#<pr>#<sha> |
1800s |
over-cap sibling not re-evaluated for 30 min |
contributor-cap-lock:<repo>:<author> |
30s |
self-heals |
On a single-instance deployment any lock present at boot is provably orphaned — the process that claimed it is gone.
Do NOT flush: delivery:* (webhook dedup — flushing re-processes recent deliveries), pr-panel-retrigger-pending:* (must survive restarts by design, #7626), ci-pending-first-seen:* (resets the stuck-CI clock), fresh-rebase-forced:* (re-arms a safety cap).
Note the contrast worth copying: the CI_STUCK_FINALIZE guard is Postgres-backed and therefore correctly restart-safe — the Redis markers are the anti-pattern.
Fix
At selfhost boot, SCAN-delete pr-actuation-lock:*, ai-review-lock:*, contributor-cap-wake:* before starting the queue. Alternative/complement: put an instance epoch id in the lock value so a new boot epoch invalidates prior-epoch locks.
Refs #8998, #9007.
There is no boot-time lock flush anywhere:
src/server.ts~690-770 wiresSELFHOST_TRANSIENT_CACHEstraight to a live Redis client with no startup purge. Every Redis-backed lock survives a container restart with its TTL intact, so #8998 (ai-review-lock, 1800s) is one instance of a general class:pr-actuation-lock:<repo>#<pr>ai-review-lock:...contributor-cap-wake:<repo>#<pr>#<sha>contributor-cap-lock:<repo>:<author>On a single-instance deployment any lock present at boot is provably orphaned — the process that claimed it is gone.
Do NOT flush:
delivery:*(webhook dedup — flushing re-processes recent deliveries),pr-panel-retrigger-pending:*(must survive restarts by design, #7626),ci-pending-first-seen:*(resets the stuck-CI clock),fresh-rebase-forced:*(re-arms a safety cap).Note the contrast worth copying: the
CI_STUCK_FINALIZEguard is Postgres-backed and therefore correctly restart-safe — the Redis markers are the anti-pattern.Fix
At selfhost boot, SCAN-delete
pr-actuation-lock:*,ai-review-lock:*,contributor-cap-wake:*before starting the queue. Alternative/complement: put an instance epoch id in the lock value so a new boot epoch invalidates prior-epoch locks.Refs #8998, #9007.