fix(fleet-monitor): token-usage summary step must not fail the whole monitor - #1247
Conversation
The 'Summarize token usage by workflow' step fetches/unzips every token-usage artifact and hit an API rate-limit (HTTP 403), failing the whole daily monitor BEFORE the load-bearing steps ran — issue tracking + the fleet-tracker auto-close (#1204) never executed, so the backlog didn't clear even after the paginate fix (#1242). This step is best-effort observability; mark it continue-on-error so a transient rate-limit can never again abort the monitor and block the auto-close. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Juznz5V6su81ffSND8fg7s
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 28 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: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ 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 |
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Dev-Lead — review-changes (no-changes)No changes were needed for this PR. |
There was a problem hiding this comment.
Pull request overview
This PR ensures the Actions Fleet Monitor’s token-usage summarization step cannot fail the overall monitor job, so downstream “load-bearing” steps (issue tracking and fleet-tracker auto-close) still execute even under transient GitHub API rate limits.
Changes:
- Mark “Summarize token usage by workflow” as
continue-on-error: trueso API-heavy artifact fetching/unzipping failures don’t abort the job. - Add inline comments documenting why the step is intentionally best-effort.
donpetry-bot
left a comment
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: LOW
Reviewed commit: 6cfc51c6aa69a52810b3b8ca398ed6e6e1935bce
Review mode: triage-approved (single reviewer)
Summary
One-line failure-semantics fix: adds continue-on-error: true (plus an explanatory comment) to the 'Summarize token usage by workflow' step in .github/workflows/actions-fleet-monitor.yml. The step is best-effort observability (fetches/unzips token-usage artifacts, writes only to $GITHUB_STEP_SUMMARY); an API rate-limit there previously aborted the whole monitor before the load-bearing issue-tracking and fleet-tracker auto-close steps ran. Verified in the file at the head SHA that no downstream step consumes this step's outputs — the temp workdir is self-cleaned and $HAS_FAILURES is set by the earlier fleet_monitor.sh step — so failing soft here cannot corrupt later steps.
Linked issue analysis
No linked closing issues. The PR is a follow-up to #1242 (paginate crash fix) and #1204 (fleet-tracker auto-close): after #1242 merged, the 2026-07-14 22:36 UTC monitor run still failed at the earlier token-summary step (HTTP 403 rate-limit), starving the auto-close. This change addresses exactly that failure mode.
Findings
- Triage assessment confirmed: the change matches its description, is minimal, and is placed on the correct step.
- Non-blocking observation:
continue-on-error: truewill also mask a persistent (non-transient) failure of the summary step — the job will show green with only a step-level annotation. Acceptable for a documented best-effort observability step; worth revisiting only if the summary silently stops appearing. - No security concerns: the step's use of
GH_PAT_WORKFLOWSis pre-existing and unchanged; no new permissions, secrets, or actions introduced. This workflow is not one of the protected thin caller stubs listed in CLAUDE.md/AGENTS.md. - Secret scan: the
run_secret_scanningMCP tool was not available in this run; the gitleaks CI check passed, and the diff adds only YAML comments and one boolean key.
CI status
All checks green at 6cfc51c: CI (Lint, ShellCheck, Agent Security Scan, Secret scan/gitleaks, Compile agentic workflows), Lint (shellcheck, bats, validate-workflow-schedules, template-drift, validate-agent-profiles, validate-personas, gh-aw-compile), CodeQL (actions + python), unit-tests, SonarCloud quality gate passed, AgentShield, Holdout Guard, Test-Deletion Guard. Remaining items are SKIPPED conditional jobs (dependabot, mention triggers, dependency-audit ecosystems).
Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.
Second-order production fix. After #1242 (the paginate crash) landed, the monitor run at 22:36 UTC still failed — but at a different, earlier step: 'Summarize token usage by workflow' hit an API rate-limit (HTTP 403) and aborted the job, so the later load-bearing steps (issue tracking + the fleet-tracker auto-close from #1204) never ran and the backlog didn't clear.
That step fetches/unzips every token-usage artifact (API-heavy) and is best-effort observability — it should never be able to fail the whole monitor. Add
continue-on-error: true.With #1242 (correct auto-close) + this, a transient rate-limit degrades gracefully: the summary is skipped, the auto-close still runs. YAML validated.
Please fast-track alongside #1242's already-merged fix — the daily monitor + backlog auto-close depend on it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Juznz5V6su81ffSND8fg7s