You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PR-fix attempt cap counts review comments, blocking multi-comment reviews before any attempt #1103
The PR-fix attempt cap from #1001 counts distinct evidence keys as attempts (src/lib/pr-fix-queue.ts, capExceeded = !isKnownEvidence && nextEvidenceKeys.length > maxPrFixAttempts()). Every inline review comment gets its own evidence key (review_comment:<repo>#<pr>:<id>), so one review with 5 or more inline comments exceeds the cap on first sight. The item goes BLOCKED/NEEDS_HUMAN before anything has worked it even once.
This happened on #1095. The PR-fix history shows it was born blocked: enqueue at 11:46:26 with lane NEEDS_HUMAN and note "Bounded at 6 attempts (PR_FIX_MAX_ATTEMPTS=5)", then "Bounded at 7 attempts" at 11:46:28. That is one CHANGES_REQUESTED review with 6 inline comments plus the review itself. The item is still at generation 1, and no fix-pr CoderRun was ever created for it. The AI reviewer routinely posts this many inline findings, so any substantive review on a coder PR bypasses the fix loop entirely.
Expected
The cap should bound fix attempts (dispatched coder runs), not the number of findings in one review. A single review, however many comments it carries, is one round of feedback.
Suggested fix
Count attempts from something that advances once per attempt. Options:
Generation is the closest match to "attempts" and is already maintained. Whichever is chosen, PR_FIX_MAX_ATTEMPTS semantics and the note text in enqueuePrFixItem should say what is counted.
Add a regression test to src/lib/pr-fix-queue.test.ts: a first enqueue of one review with 6+ review_comment keys (all at the same head) must stay QUEUED in lane NORMAL.
Related: requeuePrFixItem says it resets the attempt counter, but it leaves evidenceKeys intact, so this cap doesn't actually reset. A requeued #1095 gets one run, then re-blocks on the first new review comment (7 keys, already over 5). If the fix keeps counting from a stored field, requeue should reset that field.
Activity
joryirving commentedon Sep 27, 2026
Related:
requeuePrFixItemsays it resets the attempt counter, but it leavesevidenceKeysintact, so this cap doesn't actually reset. A requeued #1095 gets one run, then re-blocks on the first new review comment (7 keys, already over 5). If the fix keeps counting from a stored field, requeue should reset that field.fix(pr-fix): cap fix attempts, not evidence, and always baseline fres…
fix(pr-fix): deliver post-dispatch evidence as a fresh attempt (#1119) (