Repository navigation
feat(#85): bounded re-dispatch with review feedback on request_changes - #149
Conversation
When a reviewer returns request_changes and retries remain (MESH_REVIEW_RETRIES, default 2), the scheduler re-dispatches the task instead of failing it. The re-dispatched worker continues on the task's existing branch (prior commits accumulate) and receives the reviewer's notes injected into its prompt. - task.Record: add RetriesLeft int + ReviewFeedback string (persisted on KV) - task.Store.Redispatch: atomic running→pending with feedback + counter update - scheduler.Options.ReviewRetries: wired from config.ReviewRetries - handleReview: request_changes routes to handleRequestChanges; approve→done, reject→failed, error unchanged; retries exhausted request_changes→failed - worker.Spawn: when rec.Branch != "" (re-dispatch) checks out the existing branch via addWorktreeFromBranch so prior commits survive - worker.buildPrompt: injects "A reviewer requested changes..." when ReviewFeedback set - config: MESH_REVIEW_RETRIES (non-negative int, default 2) - coordinator: wires ReviewRetries into scheduler.Options Tests: TestReviewRequestChangesRedispatchesWithFeedback (re-dispatch + feedback injection), TestReviewRetriesExhaustedFailsTask (exhaustion after RETRIES re-dispatches), TestReviewRequestChangesFailsTaskWhenRetriesZero (opt-out), TestLoadReviewRetriesKnob (config parsing). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reviewer caught: ReviewFeedback=="" as the first-dispatch sentinel loops unboundedly when a reviewer returns request_changes with empty notes. Add a dedicated Record.Redispatched flag (set in Store.Redispatch), key the budget init off it, and add TestReviewRetriesExhaustedWithEmptyNotes as a regression. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_7b58c3bb-5fa0-4b26-ab80-a5195bee3794) |
|
Warning Review limit reached
Next review available in: 15 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closes #85.
Built by the dogfood mesh (Sonnet worker); the in-mesh Opus reviewer returned request_changes with a sharp, correct catch (retry budget inferred from
ReviewFeedback==""loops unboundedly when notes are empty). Director applied the reviewer's suggested fix + a regression test, then merged. (#85's own auto-redispatch isn't on main yet to self-heal this — bootstrap.)What
MESH_REVIEW_RETRIES(default 2): onrequest_changes, the scheduler re-dispatches the same task with the reviewer's notes as feedback, on the existing branch, up to N times; only fails after exhausting retries (or on reject).Record.Redispatchedflag for first-dispatch detection (not feedback-emptiness) → budget always decrements. Regression testTestReviewRetriesExhaustedWithEmptyNotes.Verification
gofmt clean ·
go build ./...·go vet ./...·go test ./internal/...green.🤖 Generated with Claude Code
Note
Medium Risk
Changes review-gate terminal behavior and task state machine (running→pending via Redispatch); bounded by tests but affects job success/failure and extra worker/review LLM spend.
Overview
Adds
MESH_REVIEW_RETRIES(default 2, 0 = fail immediately) so arequest_changesreview no longer always fails the task. The scheduler can re-dispatch the same task up to N times with reviewer notes asReviewFeedback, on the existing worker branch so prior commits accumulate.Scheduler splits
request_changesfrom reject:handleRequestChangesuses persistedRetriesLeftandRedispatched(not empty feedback) to bound retries, thentask.Store.Redispatchmoves running → pending. Worker checks out an existing branch viaaddWorktreeFromBranchand injects feedback into the prompt.Includes config/coordinator wiring,
TestLoadReviewRetriesKnob, and review-gate tests including a regression for empty reviewer notes (unbounded retry trap).Reviewed by Cursor Bugbot for commit c5ed216. Bugbot is set up for automated code reviews on this repo. Configure here.