mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-27 02:44:50 +01:00
Priya RamanandPaperclip
c83169a20e
Two admissions could independently prove the same crashed holder's gate stale and both proceed to remove it. The first removal vacates the shared path and deletes the dead gate; a fresh claimant can win that vacant path before the second admission's own removal runs. That second removal then captures the fresh claimant's live gate by mistake, forcing it through a vacate-then-restore dance that opens a further window for a claimant to overlap its critical section with the live holder recovery just displaced. Serialize recovery for one gate across every Runner process with a single well-known lock path, so at most one admission is ever mid-recovery for a given gate. Its own removal step then always captures the exact dead gate it already proved stale, so the vacate-then-restore case becomes unreachable in production. A stale lock (its holder crashed mid-recovery) is cleared by age, so a crash cannot block every later admission for the root forever. Co-authored-by: Paperclip <noreply@paperclip.ing>