Repository navigation
fix(queue-storage): make an explicit progress flush wait for the attempt lock - #726
Conversation
…mpt lock A heartbeat batch leaves out receipt attempts whose lock another transaction holds. flush_progress shared that helper, so a flush that overlapped a heartbeat or a completion of the same attempt wrote nothing and still returned Ok. The flush now waits for the lock; only heartbeat batches skip.
hardbyte
added
the
full-ci
Claude
|
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. |
…klog test The test waited for the retried jobs by counting completed rows in storage. Queue prune drops a sealed slot's completed rows once the ring wraps past it, so a recovery slower than one revolution could never reach the count. The handler now counts the recovery runs, and the test then waits for the queue to hold no running, retryable or available job.
|
Cause: the test counted completed rows in storage while the recovery client runs with eager ring rotation, so queue prune could drop a sealed slot's completed rows before the count reached its target. The fix for this on Generated by Claude Code |
…it exists Another test's stale-observation cleanup can delete the row between reports, so the poll reads it with fetch_optional instead of failing on RowNotFound.
|
Generated by Claude Code |
An explicit
flush_progress()on a receipt attempt could write nothing and still return success. Found while forward-porting #647 tomain(#725). Present in 0.6.16 and 0.6.17.Cause
#647 made the heartbeat batch leave out receipt attempts whose lock another transaction holds, through
upsert_attempt_state_progress_from_receipts_tx.flush_progresscalls the same helper, so a flush that overlapped a heartbeat or a completion of the same attempt was filtered out, the helper returned zero rows,flush_progressignored the count, and the worker treated the progress as persisted.Change
skip_locked. Heartbeat batches passtrueand behave as before;flush_progresspassesfalseand waits for the attempt's lock.test_queue_storage_flush_progress_waits_for_a_locked_receipt_attemptholds the attempt lock, checks that the flush waits, releases the lock and reads the progress back. It fails with the flush on the skip path.Not in this PR
Three other issues the same review found on
mainalso exist on 0.6 and are fixed in #725: the final progress update lost when an attempt parks for a callback, the accelerated heartbeat cutoff drifting later while rescue waits for a connection, and younger claim slots waiting behind the oldest when rescue passes do not re-arm.Generated by Claude Code