Opus finding
MAX_PROCESSING_ATTEMPTS off-by-one vs documented terminal threshold
lowmaintainabilitymedium
- apps/web/lib/review-worker.ts:30-36
- apps/web/lib/review-worker.ts:184-197
With MAX_PROCESSING_ATTEMPTS = 6: when the 6th attempt fails, attemptsAfterClaim = 6, remaining = 0, so the row is terminally failed without a 6th backoff sleep. That means only 5 backoff slots (60s..960s) are ever used as sleeps; the 1800s slot is dead. Comment says 'after the 6th failure we mark the row failed rather than schedule another retry' which is consistent, but then claims total wall-clock ≈ 60+120+240+480+960+1800 which is incorrect — the 1800s is never waited because there is no 7th attempt. Actual total ≈ 60+120+240+480+960 ≈ 31 minutes plus 5 review-runtime windows. This is a docs-vs-code mismatch the comment claims to reason from.
Recommendation
Either (a) bump MAX_PROCESSING_ATTEMPTS to 7 so all six backoff slots are used and the comment math is correct, or (b) drop the 1800 entry and correct the comment to say 'total ≈ 31 minutes'. Update the test that probes index 6 (`computeNextRetryAt(NOW, 6) === 1_800_000`) to reflect reality.