fix: call schedule_followup before send_response in step 7 - #172
Conversation
send_response() is a hard turn-terminator — no tool calls execute after it. The previous ordering (send_response first, then schedule_followup) meant the remediation follow-up was never scheduled, breaking the daily health → remediation chain. Reorder to: schedule_followup() → send_response(). Also fix the same ordering bug in the chained PR→Jira remediation follow-up. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: redhat-chai-bot The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Warning Review limit reached
Next review available in: 55 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: Repository: openshift-online/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe failure-report flow now schedules remediation before sending the summary and threaded replies. All-green reports remain unchanged. The delivery constraint documents that required follow-ups must be scheduled before ChangesRemediation delivery flow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 10 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (10 passed)
✨ 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 |
|
Hi @coderabbitai[bot] -- I can only respond automatically to comments from verified Red Hat associates. Your GitHub account could not be confirmed. If you are a Red Hat employee and believe this is an error, please ask for help in the |
|
Tip For best results, initiate chat on the files or code changes.
You are interacting with an AI system. |
- Add "Guiding principle: PR-first remediation" section establishing that PRs should be the default action, with Jira as a fallback - Expand auto-fix PRs section with fixable patterns for rosa-e2e test code, ROSA CLI tests, CI workflow/config, SRE operator tests, and OCM FVT tests - Update Jira section to explicitly position tickets as the fallback when PR-based fixes are not feasible - Fix schedule_followup/send_response ordering constraint (same bug as health report fix) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Problem
Step 7 of the daily health report task instructions tells the bot to call
schedule_followupaftersend_response(). However,send_response()is a hard turn-terminator on the Chai Bot platform — no tool calls execute after it. This meansschedule_followupnever runs, and the remediation follow-up chain (PR remediation → Jira remediation) is silently broken.The same ordering bug exists inside the PR remediation follow-up description (step 4), where it chains to the Jira remediation follow-up.
Root Cause
The task instructions assumed a
schedule_followupexception to thesend_response()turn-termination rule. This exception does not exist at the platform level. The platform instructions explicitly state:Fix
Reorder step 7 so
schedule_followupis called beforesend_response():schedule_followup(...)first, thensend_response().schedule_followupbeforesend_response().schedule_followup" carve-out; replace with guidance to callschedule_followupbeforesend_response().All follow-up description content (the quoted blocks with PR/Jira remediation instructions) is preserved — only the ordering instructions around them changed.
Impact
Without this fix, the daily health report never schedules automated remediation follow-ups, requiring manual intervention to trigger remediation each day.
@dustman9000 requested in Slack thread
Summary by CodeRabbit