claude-code - 💡(How to fix) Fix [Bug] UltraReview consumed quota on failed runs without completing review

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

/ultrareview (no-argument / current-branch form) reproducibly fails. The pipeline reaches Setup ✓ → Find ✓ → Verify ✗ ("Review failed"), and the Dedupe stage never starts. It failed 2/2 consecutive runs — and each failed run still consumed one of the 3 free /ultrareview runs.

Environment

  • Claude Code 2.1.146
  • macOS 26.5
  • Standard git repo; review target review/all-unmerged-0521 → main, ~52 files / ~4,500 insertions

Repro

  1. On a multi-commit branch, run /ultrareview with no arguments.
  2. Confirm the launch dialog; the review runs in the cloud.
  3. Watch the pipeline view.

Expected

The review completes Setup → Find → Verify → Dedupe and returns findings. A run that fails before completing should not consume a free-run credit.

Actual

  • Setup ✓
  • Find ✓ (run 1 surfaced 2 candidates; run 2 surfaced 1)
  • Verify ✗ — red error icon, header changes to "Review failed"
  • Dedupe — never starts
  • The heartbeat log pane is empty apart from a single [heartbeat] HH:MM:SS line — no error detail, no explanation of why Verify failed.

Both failed runs were still counted against the quota ("Free ultrareview 1 of 3", then "2 of 3").

Secondary bug — a failed review is indistinguishable from a clean one

When a run fails at Verify, the completion notification still reports status: completed with an empty findings array []. Anything consuming the result — or a user reading "0 findings" — cannot tell a failed review from a genuinely clean one. A failed run should surface a distinct error status rather than completed + [].

Failed sessions

  • Run 1 — session_01ShwA5SdXgiaYr3gqs5qr2L
  • Run 2 — session_018meDNWV8cSGTmVi4A82ZWU

Impact

  • /ultrareview is currently unusable on this repo (2/2 runs failed).
  • 2 of 3 free runs consumed for zero completed reviews.
  • The completed + []-on-failure behavior risks a false "clean review" signal to both users and tooling.
<img width="1406" height="485" alt="Image" src="https://github.com/user-attachments/assets/2b210e18-c1ad-4b06-81b6-e78b236bfe18" /> <img width="1390" height="488" alt="Image" src="https://github.com/user-attachments/assets/b61be278-0885-4e88-9f3c-0a5dabf89b44" />

Error Message

  • Verify ✗ — red error icon, header changes to "Review failed" line — no error detail, no explanation of why Verify failed. distinct error status rather than completed + [].

Root Cause

/ultrareview (no-argument / current-branch form) reproducibly fails. The pipeline reaches Setup ✓ → Find ✓ → Verify ✗ ("Review failed"), and the Dedupe stage never starts. It failed 2/2 consecutive runs — and each failed run still consumed one of the 3 free /ultrareview runs.

Environment

  • Claude Code 2.1.146
  • macOS 26.5
  • Standard git repo; review target review/all-unmerged-0521 → main, ~52 files / ~4,500 insertions

Repro

  1. On a multi-commit branch, run /ultrareview with no arguments.
  2. Confirm the launch dialog; the review runs in the cloud.
  3. Watch the pipeline view.

Expected

The review completes Setup → Find → Verify → Dedupe and returns findings. A run that fails before completing should not consume a free-run credit.

Actual

  • Setup ✓
  • Find ✓ (run 1 surfaced 2 candidates; run 2 surfaced 1)
  • Verify ✗ — red error icon, header changes to "Review failed"
  • Dedupe — never starts
  • The heartbeat log pane is empty apart from a single [heartbeat] HH:MM:SS line — no error detail, no explanation of why Verify failed.

Both failed runs were still counted against the quota ("Free ultrareview 1 of 3", then "2 of 3").

Secondary bug — a failed review is indistinguishable from a clean one

When a run fails at Verify, the completion notification still reports status: completed with an empty findings array []. Anything consuming the result — or a user reading "0 findings" — cannot tell a failed review from a genuinely clean one. A failed run should surface a distinct error status rather than completed + [].

Failed sessions

  • Run 1 — session_01ShwA5SdXgiaYr3gqs5qr2L
  • Run 2 — session_018meDNWV8cSGTmVi4A82ZWU

Impact

  • /ultrareview is currently unusable on this repo (2/2 runs failed).
  • 2 of 3 free runs consumed for zero completed reviews.
  • The completed + []-on-failure behavior risks a false "clean review" signal to both users and tooling.
<img width="1406" height="485" alt="Image" src="https://github.com/user-attachments/assets/2b210e18-c1ad-4b06-81b6-e78b236bfe18" /> <img width="1390" height="488" alt="Image" src="https://github.com/user-attachments/assets/b61be278-0885-4e88-9f3c-0a5dabf89b44" />
RAW_BUFFERClick to expand / collapse

Summary

/ultrareview (no-argument / current-branch form) reproducibly fails. The pipeline reaches Setup ✓ → Find ✓ → Verify ✗ ("Review failed"), and the Dedupe stage never starts. It failed 2/2 consecutive runs — and each failed run still consumed one of the 3 free /ultrareview runs.

Environment

  • Claude Code 2.1.146
  • macOS 26.5
  • Standard git repo; review target review/all-unmerged-0521 → main, ~52 files / ~4,500 insertions

Repro

  1. On a multi-commit branch, run /ultrareview with no arguments.
  2. Confirm the launch dialog; the review runs in the cloud.
  3. Watch the pipeline view.

Expected

The review completes Setup → Find → Verify → Dedupe and returns findings. A run that fails before completing should not consume a free-run credit.

Actual

  • Setup ✓
  • Find ✓ (run 1 surfaced 2 candidates; run 2 surfaced 1)
  • Verify ✗ — red error icon, header changes to "Review failed"
  • Dedupe — never starts
  • The heartbeat log pane is empty apart from a single [heartbeat] HH:MM:SS line — no error detail, no explanation of why Verify failed.

Both failed runs were still counted against the quota ("Free ultrareview 1 of 3", then "2 of 3").

Secondary bug — a failed review is indistinguishable from a clean one

When a run fails at Verify, the completion notification still reports status: completed with an empty findings array []. Anything consuming the result — or a user reading "0 findings" — cannot tell a failed review from a genuinely clean one. A failed run should surface a distinct error status rather than completed + [].

Failed sessions

  • Run 1 — session_01ShwA5SdXgiaYr3gqs5qr2L
  • Run 2 — session_018meDNWV8cSGTmVi4A82ZWU

Impact

  • /ultrareview is currently unusable on this repo (2/2 runs failed).
  • 2 of 3 free runs consumed for zero completed reviews.
  • The completed + []-on-failure behavior risks a false "clean review" signal to both users and tooling.
<img width="1406" height="485" alt="Image" src="https://github.com/user-attachments/assets/2b210e18-c1ad-4b06-81b6-e78b236bfe18" /> <img width="1390" height="488" alt="Image" src="https://github.com/user-attachments/assets/b61be278-0885-4e88-9f3c-0a5dabf89b44" />

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] UltraReview consumed quota on failed runs without completing review