An automated review of #1189 flagged a fairness gap in the BReg review worker's authority pass. In crates/registry-breg/src/review_store.rs, run_one walks its work classes in a fixed order and returns Ok(true) as soon as one unit of work succeeds: submissions first, then cancellations, then the result feed, then result polls.
Failure scenario: pending submissions stay continuously ready, so every pass ends in the submissions loop and the cancellation and result loops below never run. ReviewWorker already stops application jobs from starving authority work, but sustained submission traffic can still starve accepted or cancelling reviews until their recovery or result-retention windows expire.
Suggested fix:
- Rotate the authority work classes across passes (round-robin or a per-class cursor) instead of always restarting at submissions.
- Add a Postgres test with continuously ready submissions that asserts a pending cancellation and a due result poll still make progress.
Filed from the review of #1189; not merge-blocking.
An automated review of #1189 flagged a fairness gap in the BReg review worker's authority pass. In
crates/registry-breg/src/review_store.rs,run_onewalks its work classes in a fixed order and returnsOk(true)as soon as one unit of work succeeds: submissions first, then cancellations, then the result feed, then result polls.Failure scenario: pending submissions stay continuously ready, so every pass ends in the submissions loop and the cancellation and result loops below never run.
ReviewWorkeralready stops application jobs from starving authority work, but sustained submission traffic can still starve accepted or cancelling reviews until their recovery or result-retention windows expire.Suggested fix:
Filed from the review of #1189; not merge-blocking.