t1097: Add prompt-repeat retry strategy to dispatch.sh#1631
t1097: Add prompt-repeat retry strategy to dispatch.sh#1631marcusquinn merged 2 commits intomainfrom
Conversation
Before escalating to a more expensive model tier on worker failure, retry with a reinforced prompt at the same tier. Many failures are due to insufficient prompt clarity (missing completion signals, no PR created) rather than model capability limitations. Strategy: should_prompt_repeat() checks eligibility (config toggle, not already attempted, retryable failure, pattern tracker data), then do_prompt_repeat() dispatches with build_prompt_repeat_prompt() which doubles down on requirements and failure-specific guidance. Pattern tracker integration: records SUCCESS_PATTERN/FAILURE_PATTERN with prompt_repeat tag so future routing decisions are data-driven. With 3+ samples and <25% success rate, prompt-repeat is auto-skipped. Configurable via SUPERVISOR_PROMPT_REPEAT_ENABLED (default: true). DB migration adds prompt_repeat_done column to tasks table.
|
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 introduces a strategic enhancement to the supervisor's task retry mechanism. Instead of immediately escalating to a more expensive model upon task failure, the system will now first attempt a 'prompt-repeat' retry. This involves re-dispatching the task with a more explicit and reinforced prompt at the same model tier. This change is designed to address common failures caused by insufficient prompt clarity, thereby improving task completion rates and reducing operational costs by optimizing model usage based on learned patterns. 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: Wed Feb 18 02:47:33 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 'prompt-repeat' retry strategy, which is a sensible approach to handling certain types of task failures before escalating to more expensive models. The implementation is well-structured across dispatch.sh, pulse.sh, and database.sh. The new functions in dispatch.sh are robust, using safe patterns for command construction and background execution. The integration into pulse.sh correctly places the new logic before model escalation.
My review includes two suggestions for improvement: one for code deduplication in pulse.sh to enhance maintainability, and another for a minor performance optimization in dispatch.sh by avoiding a redundant command execution.
| pr_success=$("$pattern_helper" stats 2>/dev/null | | ||
| grep -c 'prompt_repeat.*SUCCESS\|SUCCESS.*prompt_repeat' 2>/dev/null || echo "0") | ||
| pr_failure=$("$pattern_helper" stats 2>/dev/null | | ||
| grep -c 'prompt_repeat.*FAILURE\|FAILURE.*prompt_repeat' 2>/dev/null || echo "0") |
There was a problem hiding this comment.
The "$pattern_helper" stats command is executed twice here. To improve efficiency, especially if the helper script has a non-trivial execution time, you could call it once and store its output in a variable. Then, you can pipe the variable's content to grep for both success and failure counts.
| pr_success=$("$pattern_helper" stats 2>/dev/null | | |
| grep -c 'prompt_repeat.*SUCCESS\|SUCCESS.*prompt_repeat' 2>/dev/null || echo "0") | |
| pr_failure=$("$pattern_helper" stats 2>/dev/null | | |
| grep -c 'prompt_repeat.*FAILURE\|FAILURE.*prompt_repeat' 2>/dev/null || echo "0") | |
| local stats_output | |
| stats_output=$("$pattern_helper" stats 2>/dev/null) | |
| pr_success=$(echo "$stats_output" | grep -c 'prompt_repeat.*SUCCESS\|SUCCESS.*prompt_repeat' 2>/dev/null || echo "0") | |
| pr_failure=$(echo "$stats_output" | grep -c 'prompt_repeat.*FAILURE\|FAILURE.*prompt_repeat' 2>/dev/null || echo "0") |
There was a problem hiding this comment.
Fixed in 66ed098. Cached the stats output in a local variable so it's only called once, then piped to both grep commands.
.agents/scripts/supervisor/pulse.sh
Outdated
| local tid_pr_done_retry | ||
| tid_pr_done_retry=$(db "$SUPERVISOR_DB" "SELECT COALESCE(prompt_repeat_done, 0) FROM tasks WHERE id = '$(sql_escape "$tid")';" 2>/dev/null || echo "0") | ||
| if [[ "$tid_pr_done_retry" -ge 1 ]]; then |
There was a problem hiding this comment.
This block of code to check if a prompt-repeat was attempted is duplicated from lines 275-277. According to the general repository rules, repeated logic should be extracted into an internal helper function to improve maintainability.
For example, you could create a function like _was_prompt_repeat_attempted() at the top of the script:
# Internal helper to check if a task has had a prompt-repeat attempt.
# Args: $1 = task_id
# Returns: 0 if attempted, 1 if not.
_was_prompt_repeat_attempted() {
local task_id="$1"
local prompt_repeat_done
prompt_repeat_done=$(db "$SUPERVISOR_DB" "SELECT COALESCE(prompt_repeat_done, 0) FROM tasks WHERE id = '$(sql_escape "$task_id")';" 2>/dev/null || echo "0")
if [[ "$prompt_repeat_done" -ge 1 ]]; then
return 0
fi
return 1
}Then you can replace both occurrences with a simple call:
if _was_prompt_repeat_attempted "$tid"; then
# ... logic ...
fiReferences
- In shell scripts, extract repeated logic into an internal helper function to improve maintainability. This applies even for standalone scripts where external
sourcedependencies are avoided.
There was a problem hiding this comment.
Fixed in 66ed098. Extracted _was_prompt_repeat_attempted() helper function at the top of pulse.sh and replaced both inline DB queries with calls to it.
🔍 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: Wed Feb 18 03:07:06 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
…d t1094.1 (t1107) All t1094 deliverables confirmed implemented: - Prompt strategy tracking → t1095 (pr:#1629) - Output quality gradient + failure categorization → t1096 (pr:#1632) - Token usage → t1095 (pr:#1629) - A/B comparison → t1098+t1099 (pr:#1637, pr:#1634) - Prompt-repeat strategy → t1097 (pr:#1631) - Build-agent reference → t1094.1 (pr:#1633) t1094 parent ready to be marked complete: verified:2026-02-18
1 participant
Summary
Add a prompt-repeat retry strategy to the supervisor dispatch pipeline that retries failed tasks with a reinforced prompt at the same model tier before escalating to a more expensive model.
Problem
Many worker failures are due to insufficient prompt clarity (e.g., worker exits without emitting FULL_LOOP_COMPLETE, does not create a PR, produces trivial output) rather than model capability limitations. The current flow immediately escalates to a higher-tier model on retry, which is ~2-5x more expensive and often unnecessary.
Solution
Insert a prompt-repeat step before model escalation in the pulse retry handler:
Files Changed
Configuration
Ref #1622