Repository navigation
Keep busy retained recovery from blocking unrelated batches (0.6) - #666
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
|
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
A busy claim-head row encountered during retained-body recovery could roll back an entire rescue or worker completion batch, delaying unrelated work.
Rescue now selects and hydrates inside a savepoint. It defers the exact historical attempts whose required claim heads are busy, rolls back their partial transitions, and retries only the original selected population. Receipt cursors retain the deferred open evidence, so the attempt remains eligible. Missing or ambiguous bodies still fail explicitly.
Public completion methods retain their atomic NOWAIT errors. Only the worker batcher handles SQLSTATE 55P03 by retrying each original request individually. Successful requests receive success, a genuinely busy request keeps its database error, and a genuinely stale request receives a stale acknowledgment. Carried runtime jobs and successful duplicate pairs keep their existing behavior. Flush timing includes fallback work.
This backports the contention correction from #664 onto #663/#665. It preserves the 0.6 receipt deadline path and does not include the optional rescue-drain changes in #647, #648 or #650. There are no schema changes or new strong relation locks. Ordinary rescue adds a savepoint and candidate predicates; historical contention can cause bounded retries.
Validation:
59649b2epasses all 31 jobs, including both database majors and both tested Python versions.The retained-body recovery limitations documented in #663 remain.