t1041: Fix review thread resolution loop blocking queue flow#1401
t1041: Fix review thread resolution loop blocking queue flow#1401marcusquinn merged 1 commit intomainfrom
Conversation
Root cause: fix workers address review feedback but can't resolve GitHub review threads (only author/admin can). The same threads get re-triaged every pulse, dispatching another fix worker in an infinite loop until the 3-cycle cap blocks the task. Three fixes: 1. Add resolve_bot_review_threads() — resolves bot threads via GraphQL mutation after a fix worker cycle, before re-triaging 2. Separate human vs bot severity in triage — bot-only medium/low threads no longer trigger fix workers (they're style nits, not merge-blockers) 3. Only human-sourced high/critical threads gate merging; bot criticals get one fix attempt then resolve This unblocks t1032.3, t1032.5, t1032.8 and prevents future fix-worker exhaustion loops.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ 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 |
Summary of ChangesHello @marcusquinn, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical issue where automated review processes could get stuck in an infinite loop due to unresolved bot-generated review threads. By introducing a mechanism to automatically resolve these bot threads and refining the review triage logic to prioritize human feedback, the changes ensure a smoother and more efficient PR workflow. This significantly improves the system's ability to process pull requests without manual intervention for bot-related feedback, thereby unblocking several pending tasks and enhancing overall system reliability. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Fri Feb 13 17:32:11 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a solid fix for the review thread resolution loop. The new resolve_bot_review_threads function and the updated triage logic are well-designed to address the problem. The existing comments, which align with the repository's shell scripting style guide concerning error logging and function argument handling, remain valid and are included as-is. Addressing these points will enhance the script's robustness and maintainability.
| prior_fix_cycles=$(db "$SUPERVISOR_DB" " | ||
| SELECT COUNT(*) FROM state_log | ||
| WHERE task_id = '$escaped_id' | ||
| AND from_state = 'review_triage' | ||
| AND to_state = 'dispatched'; | ||
| " 2>/dev/null || echo "0") |
There was a problem hiding this comment.
The use of 2>/dev/null here violates the repository style guide (Rule #50), which disallows blanket error suppression. Errors from the db command should be logged to aid in debugging, even if a default value is provided on failure. Please redirect stderr to $SUPERVISOR_LOG.
| prior_fix_cycles=$(db "$SUPERVISOR_DB" " | |
| SELECT COUNT(*) FROM state_log | |
| WHERE task_id = '$escaped_id' | |
| AND from_state = 'review_triage' | |
| AND to_state = 'dispatched'; | |
| " 2>/dev/null || echo "0") | |
| prior_fix_cycles=$(db "$SUPERVISOR_DB" " | |
| SELECT COUNT(*) FROM state_log | |
| WHERE task_id = '$escaped_id' | |
| AND from_state = 'review_triage' | |
| AND to_state = 'dispatched'; | |
| " 2>>"$SUPERVISOR_LOG" || echo "0") |
References
- Rule 50:
2>/dev/nullis acceptable only when redirecting to log files, not for blanket error suppression. Errors should be logged for better diagnostics. (link)
| local repo_slug="$1" | ||
| local pr_number="$2" |
There was a problem hiding this comment.
According to the repository style guide (Rule #11), function parameters should be declared and assigned separately for safety when set -e is active. Please refactor this to:
local repo_slug
repo_slug="$1"
local pr_number
pr_number="$2"References
- Rule 11: Use
local varandvar="$1"on separate lines for function arguments to avoid unexpected exits underset -e. (link)
| bot_thread_ids=$(echo "$result" | jq -r ' | ||
| [.data.repository.pullRequest.reviewThreads.nodes[] | ||
| | select(.isResolved == false) | ||
| | select((.comments.nodes[0].author.login // "") | test("bot$|\\[bot\\]$|gemini|coderabbit|copilot|codacy|sonar"; "i")) | ||
| | .id | ||
| ] | .[]' 2>/dev/null || echo "") |
There was a problem hiding this comment.
The use of 2>/dev/null here violates the repository style guide (Rule #50), which states that stderr should not be suppressed this way. Suppressing jq errors can hide problems with the GraphQL response format or the jq filter itself. Please redirect stderr to the supervisor log for better diagnostics.
| bot_thread_ids=$(echo "$result" | jq -r ' | |
| [.data.repository.pullRequest.reviewThreads.nodes[] | |
| | select(.isResolved == false) | |
| | select((.comments.nodes[0].author.login // "") | test("bot$|\\[bot\\]$|gemini|coderabbit|copilot|codacy|sonar"; "i")) | |
| | .id | |
| ] | .[]' 2>/dev/null || echo "") | |
| bot_thread_ids=$(echo "$result" | jq -r ' | |
| [.data.repository.pullRequest.reviewThreads.nodes[] | |
| | select(.isResolved == false) | |
| | select((.comments.nodes[0].author.login // "") | test("bot$|\\[bot\\]$|gemini|coderabbit|copilot|codacy|sonar"; "i")) | |
| | .id | |
| ] | .[]' 2>>"$SUPERVISOR_LOG" || echo "") |
References
- Rule 50:
2>/dev/nullis acceptable only when redirecting to log files, not for blanket error suppression. Errors should be logged for better diagnostics. (link)
1 participant
Summary
resolve_bot_review_threads()— resolves bot threads via GraphQLresolveReviewThreadmutation after a fix worker cycle completes, before re-triagingImpact
Unblocks 5 stuck tasks (t1032.1, t1032.2, t1032.3, t1032.5, t1032.8) and prevents all future fix-worker exhaustion loops.
Testing
resolveReviewThreadmutation works on PR t1032.5: Wire Phase 10b to unified audit orchestrator #1377 (resolved 1 bot thread, PR now has 0 unresolved)Files Changed
.agents/scripts/supervisor/deploy.sh— newresolve_bot_review_threads()function, updatedtriage_review_feedback()severity logic, added pre-triage resolution step inreview_triagehandler