Opus finding
Cron retries do not gate on nextRetryAt — pending_retry rows can be re-attempted immediately
mediumbugmedium
- apps/web/lib/review-retry.ts:67-75
- apps/web/lib/review-worker.ts:184-197
The comment in allowedClaimSources says the loader query applies the staleness/nextRetryAt filter. loadReviewsReadyForRetry's implementation lives in @/db/queries (not in this PR slice) so this finding is best-effort. If that loader does not filter pending_retry rows by next_retry_at <= now, the backoff schedule is purely advisory and the cron will pound on freshly-failed rows every 2 minutes. The retry test (review-retry.test.ts) hands the loader's args back (now, stuckBefore, limit) but does not pass next_retry_at thresholds, suggesting the loader is responsible — worth verifying. If indeed the loader compares next_retry_at <= now this is fine; otherwise the documented backoff is silently bypassed.
Recommendation
Audit @/db/queries.loadReviewsReadyForRetry to confirm it includes `(processing_status = 'pending') OR (processing_status = 'pending_retry' AND next_retry_at <= now) OR (processing_status = 'in_progress' AND processing_started_at <= stuckBefore)`. Add an integration test (or doc test) verifying that a pending_retry row with future next_retry_at is excluded.