Fix gather-extra post-phase failures to show contextual message instead of re-trigger suggestion#120
Conversation
…ad of re-trigger suggestion
|
Warning Review limit reached
Next review available in: 50 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: Enterprise Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds Changesgather-extra failure detection and Slack messaging
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@bugzooka/analysis/failure_keywords.py`:
- Line 7: Move the `gather-extra` entry ahead of `gather` in `FAILURE_KEYWORDS`
so `classify_failure_type()` in `log_summarizer` matches the more specific
substring first. Keep the ordering in `failure_keywords.py` consistent with the
first-match behavior used by `classify_failure_type()` so `post phase:
gather-extra failure` is categorized as `gather-extra` instead of `Must Gather`.
In `@bugzooka/integrations/slack_fetcher.py`:
- Around line 269-276: The post-phase guidance copy in the Slack fetcher is
inverted for `gather-extra` failures. Update the `retrigger_message` text in
`SlackFetcher` so it reflects the new behavior: the main workload may have
completed successfully and performance results may still be available, instead
of saying it appears to be a general workload failure. Keep the
`get_slack_message_blocks` call as-is and only adjust the guidance wording used
for the post-phase context.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 267f3e24-6538-41a0-a61b-f1db332dbb4f
📒 Files selected for processing (3)
bugzooka/analysis/failure_keywords.pybugzooka/analysis/prow_analyzer.pybugzooka/integrations/slack_fetcher.py
Issue
gather-extrafailures in post phase were incorrectly categorized asmaintenance issuewithis_install_issue=True, causing BugZooka to suggest re-triggering the run. However, gather-extra runs at the end of the pipeline after the main workload completes, so these failures aren't installation issues. The actual test may have passed and performance results are still available. Below is the specific slack messageFix
The fix correctly identifies post-phase and test-phase failures as non-installation issues by checking the phase type rather than defaulting to maintenance issues. It then adds special handling for gather-extra failures to display a contextual message explaining the situation. Specific changes:
failure_keywords.py: Added mapping to recognizegather-extra stepsin categorizationprow_analyzer.py: Dynamically decided whether an issue was related to installation based onstep_phaseand preserved correct categorization message instead of overwriting withmaintenance issueslack_fetcher.py: Better messaging based on error