fix(search): refuse overlapping Search retirement runs with a session lock - #8524
waleedlatif1 wants to merge 1 commit into
Conversation
… lock A plain operator run took no lock, so two runs could double the load on the primary. Retirement now takes a session try-lock, as maintenance already does, and refuses to start while another run holds it.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
|
There was a problem hiding this comment.
All reported issues were addressed across 3 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 3 files
Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.
Re-trigger cubic
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Summary
This follows up on #8522 and addresses its Greptile finding, "Plain runs lack the documented lock".
The operator command's plain retirement run took no lock. The runbook says it holds a session advisory lock. Two overlapping runs could not corrupt progress, because every page locks the progress row, but they would double the load on the primary.
Retirement now takes a session try-lock (
search-embedding-retirement), the same pattern maintenance already uses (0028). It refuses to start while another run holds the lock, and it releases the lock infinally.Behaviour changes
Test plan
packages/dbintegration suite then passed 129/129 three times in a row.packages/dbtype-check andbun run check:auditspass.