An automated review of #1189 flagged an ordering problem in the review clock worker. In crates/registry-casework/src/review.rs, the due-step loop tests casework_queue_service for the step's destination queue before the casework_review_clock_effects conflict check that would reveal the step was already applied. An unserved destination defers the whole occurrence by 30 seconds.
Failure scenario: a reassignment step is applied while its destination queue is served, and the queue later loses its service row. On the next pass the worker re-examines that already-applied step, finds the destination unserved, and defers the occurrence. It never reaches a later due step that would move the task to a currently served queue, so the occurrence stalls indefinitely.
Suggested fix:
- Load or check the applied effects before testing the destination's service coverage, and skip steps already recorded in
casework_review_clock_effects.
- Add a Postgres test where a step is applied, its destination is unserved afterwards, and a later due step must still run.
Filed from the review of #1189; not merge-blocking.
An automated review of #1189 flagged an ordering problem in the review clock worker. In
crates/registry-casework/src/review.rs, the due-step loop testscasework_queue_servicefor the step's destination queue before thecasework_review_clock_effectsconflict check that would reveal the step was already applied. An unserved destination defers the whole occurrence by 30 seconds.Failure scenario: a reassignment step is applied while its destination queue is served, and the queue later loses its service row. On the next pass the worker re-examines that already-applied step, finds the destination unserved, and defers the occurrence. It never reaches a later due step that would move the task to a currently served queue, so the occurrence stalls indefinitely.
Suggested fix:
casework_review_clock_effects.Filed from the review of #1189; not merge-blocking.