fix(coding-agent): a review round is never refused for its length (TASK-901) - #935
Conversation
β¦SK-901) The owner's 4000-character task limit (MAX_TASK_CHARS) was applied in startRun to every start, including the follow-ups the box writes itself. A review-loop round quotes GitHub's failing-check logs and review comments (buildReviewFeedback bounds that at 24 000 characters), so PR #926's four CodeRabbit threads made the round's task too long, the start was refused with "The task is too long: at most 4000 characters.", and the pull request was handed back unreviewed. The round never embeds the original task β it resumes the session that holds it and names the pull request β so nothing needed truncating there. Instead, tasks the box wrote (review pass, review-loop round, Vercel deploy-fix turn) get their own ceiling, MAX_BOX_TASK_CHARS (32 000, above what those builders produce), and are clipped to it rather than refused. Typed tasks keep the 4000 limit unchanged. Tests: a 6000-character primary task whose round quotes four full-length review threads and a failing check now starts its round (it settled needs_owner before); a box-written task past its own ceiling is clipped, a typed one past 4000 is still refused. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. π βΉοΈ Recent review infoβοΈ Run configurationConfiguration used: Repository: ID-Robots/clawbox/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: π Files selected for processing (3)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. π WalkthroughWalkthroughThe change adds separate size limits for typed and internally generated tasks. Oversized typed tasks remain rejected. Oversized review, review-loop, and deployment-fix tasks are truncated and marked before execution. ChangesTask Length Handling
Priority: β¬οΈ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Suggested reviewers: π₯ Pre-merge checks | β 6β Passed checks (6 passed)
β¨ Finishing Touchesπ Generate docstrings
π§ͺ Generate unit tests (beta)
Comment |
What broke (TASK-901)
On 2026-09-18 run-q3tjkwm3 (TASK-899) opened PR #926, and the box could not start its review round:
The pull request was handed back
needs_ownerwith itsprphaseblocked, and no round was spent on it.Why
startRunran every task throughnormalizeTask, which refuses anything overMAX_TASK_CHARS(4 000). That limit was meant for what a person types, but it also applied to the follow-ups the box writes itself.A review-loop round's task comes from
buildReviewFeedback(src/lib/coding-review-state.ts). It quotes GitHub's failing-check logs (up to 5 Γ 2 000 chars) and unresolved review threads (up to 20 Γ 1 000 chars), and is capped atMAX_FEEDBACK_CHARS= 24 000. So any PR with a few CodeRabbit comments produced a round thatstartRunrefused. PR #926 had 4 review threads totalling 17 385 characters (measured withgh api .../pulls/926/comments).The round does not embed the original task text. It resumes the session that holds that task and names the pull request, branch and base. So there was nothing to truncate or summarise there. The run id is already how the original task is referenced.
The fix
MAX_TASK_CHARSstill applies, unchanged, to typed tasks (owner or assistant):startRun,createDraftRun, the/runand/draftroutes and the MCP tool schema.reviewOf), a review-loop round (reviewLoopOf) and a Vercel deploy-fix turn (vercelFixOf). No route passes those fields through from a request body, so a typed task can't claim the exemption.MAX_BOX_TASK_CHARS= 32 000. That is above anything the builders produce today (review feedback β€ 24 014). A task over it is clipped, ending in\nβ¦(truncated), and never refused. The length of a task the box wrote is never the reason a follow-up fails to start.The task text goes to the harness on stdin, and the MCP layer only shows its first line, so a longer task needed nothing else downstream. Team planner, worker and reviewer tasks already trim themselves to
MAX_TASK_CHARSand are left as they were.Tests
coding-review-loop.test.tsβΊ a round longer than the owner's task limit:CHANGES_REQUESTED, and four review threads at the parser's full 1 000 characters each.fixMode: "resumed", the fix run completes and the loop reachesclean.MAX_TASK_CHARSand contains every thread and the check log, with nothing truncated. It does not re-embed the primary task.needs_owner, which is the incident.buildReviewFeedbackoutput (every cap overrun) and a 200-filereviewPassTaskunderMAX_BOX_TASK_CHARS.coding-agent.test.ts: a typed continuation over 4 000 characters is still refusedinvalid. A box-written round overMAX_BOX_TASK_CHARSstarts, clipped to exactly that length with the marker.Verification (this pass)
Run on this branch (origin/beta 67a8e6d + this commit). tsc ran first, on its own, with the larger heap this device needs:
NODE_OPTIONS=--max-old-space-size=8192 bunx tsc --noEmit -p tsconfig.json: exit 0, no errors.NODE_OPTIONS=--max-old-space-size=8192 bun run test: exit 0.bunx eslint src/lib/coding-agent.ts src/tests/unit/coding-agent.test.ts src/tests/unit/coding-review-loop.test.ts: exit 0, no problems.coding-agent.tschange reverted and the new tests kept, all 3 new tests fail. The 6 000-character round test fails withexpected 'needs_owner' to be 'clean'.π€ Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests