Fence bulk review result-poll backoff to the lease holder
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
Research direction
Start in crates/registry-breg/src/review_store.rs:793-807, then read the lease-fence invariant at lines 2133-2135 and the nearby per-row backoff update. Done means the bulk backoff cannot move next_result_poll_at for rows outside the worker's lease while still updating rows held by that worker.
Written by the indexing model from the issue text.
Description
A bulk backoff update in BReg's review-result polling is not fenced to the lease holder, contradicting the fence invariant the surrounding code otherwise follows. As of PR #1189, crates/registry-breg/src/review_store.rs:793-807 pushes next_result_poll_at forward by 5 seconds for every due "accepted" row of an authority whose result lookup just failed, matched only on authority=$1 AND state='accepted' AND next_result_poll_at <= transaction_timestamp(), with no lease_until predicate. This contradicts the fence invariant documented a bit further down at review_store.rs:2133-2135 ("The lease fence keeps a worker that lost its claim ... from republishing a backoff over the new holder's schedule"), which the per-row backoff update a few lines later does respect via AND lease_until=$4.
Failure scenario: a worker that lost its lease on one row (expired, reclaimed by another worker) can still push back next_result_poll_at for every other due row under the same authority, including rows a different worker now holds the lease for, delaying that worker's next poll attempt by up to 5 seconds. At the default 5 second poll cadence this is effectively harmless, but it is a real gap in the fencing discipline the rest of the file establishes.
Suggested fix:
- Add the same
lease_untilfence to this bulkUPDATE, or scope it explicitly to rows this worker currently leases.
Filed from the review of #1189; not merge-blocking.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 3h 45m
- Merged PRs (30d)
- 134
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from registrystack/registry-stack
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
registrystack/registry-stack#1239 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
registrystack/registry-stack#1235 ·
-
area:breg bug good first issue rust
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
registrystack/registry-stack#1227 ·
-
area:casework documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1217 ·
-
area:breg documentation
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
registrystack/registry-stack#1213 ·
All issues in registrystack/registry-stack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100