Quota-exhaustion graceful skip is unreachable: the guard is gated on the step that quota exhaustion always fails

[dem-extra1]

claude-code-review.yml has a purpose-built path for quota exhaustion: skip the review with a warning instead of failing the check. It cannot fire, because the step that detects quota exhaustion only runs when the step that quota exhaustion always fails has succeeded.

Surfaced by the 2026-07-28 outage, where roughly six review runs across three unrelated branches all went red over about eight hours. Every one of them should have been a warning and a skip.

The chain

check-review-execution.sh has the detector, and it matches the real signature exactly (lines 62-72):

if [[ "$is_error" == "true" || "$subtype" == error_* ]]; then
  # total_cost_usd==0 with num_turns==1 means the API rejected the
  # request before any real processing -- quota exhaustion, auth
  # failure, or an immediate network error. Skip gracefully.
  if [[ "$total_cost" == "0" && "$num_turns" == "1" ]]; then
    echo "quota_exhausted=true" >> "$GITHUB_OUTPUT"

The observed result object:

{"type":"result","subtype":"success","is_error":true,"duration_ms":643,
 "num_turns":1,"total_cost_usd":0,"permission_denials_count":0}

is_error true, total_cost_usd 0, num_turns 1 -- a direct hit.

But the guard wrapping that script is gated on the action step's outcome (line 652):

- name: Fail the check if the review did not complete (attempt 1)
  id: fail-check
  if: steps.claude-review.outcome == 'success'
  continue-on-error: true
  uses: d-morrison/gha/.github/actions/run-review-guard@v2

And on quota exhaustion claude-code-action fails its own step first:

##[error]Claude result reported subtype success with is_error:true (run did not complete successfully)
##[error]Action failed with error: Claude execution failed: result is_error:true
##[error]Process completed with exit code 1.

So steps.claude-review.outcome is failure, the guard is skipped, quota_exhausted is never written, "Resolve final review outcome" sees a failed attempt with no flag, and the job fails for real. In the run logs the resolve step's rendered script shows "skipped" substituted where the guard's outcome should be -- visible confirmation the guard never ran.

Everything downstream that consumes the flag is therefore dead code in this scenario: the notice step at line 791, and the require-review job's if: (around line 1051, whose own comment explains that quota_exhausted=true is what keeps the gate from going red).

Two things that look like fixes but are not

Adding continue-on-error: true to the claude-review step. outcome reports the status before continue-on-error is applied; only conclusion reflects it. The gate would still read failure.

Waiting for the quota to reset. The warning text tells the reader to "re-trigger the review once the quota resets", which is right, but the check has already gone red by then, and require-review stays red on every open PR until someone re-runs each one by hand.

Suggested fix

Gate the guard on the execution file being available rather than on the action's outcome. check-review-execution.sh already handles a missing file with a clear error (lines 46-49), so always() is safe too:

if: always() && steps.exec-file.outcome == 'success'

Note exec-file (line 642) carries the same steps.claude-review.outcome == 'success' gate, so it needs widening in the same way. The execution file does exist in this scenario -- the log shows Log saved to /home/runner/work/_temp/claude-execution-output.json before the action errors -- and upload-review-execution already has a temp-path fallback for resolving it.

Worth checking the retry block's equivalent gates (lines 707, 716, 718) at the same time, since they mirror this shape.

Testing

scripts/tests/fixtures/ already has canned execution-output fixtures, and the quota case may already be among them -- if the script is tested but the workflow's gating is not, that is precisely how this survived. The gap is the same class the run-review-guard end-to-end steps were added for after gha#196: the unit was right and the wiring around it was not.

Found while investigating why PR #348's checks were red; the account was quota-exhausted, which is exactly the condition this path exists to handle.

[dem-extra1]

Fresh evidence: the same unreachable-guard shape, on a failure that is not quota exhaustion

Not a new issue --- adding a case to this one, because it shows the defect is broader than the title suggests and is currently costing real review rounds on #357.

What happened

review / claude-review on #357 at head d508f01, run 30485068173, job 90688600980:

Step	Conclusion	Duration
10. Run Claude Code Review	failure	19:35:36 -> 20:02:16 (~27 min)
11. Resolve and upload execution file path	skipped
12. Fail the check if the review did not complete (attempt 1)	skipped
13. Retry Claude Code Review after a stub result	skipped
17. Resolve final review outcome	failure
19. Post review comment	skipped

So: no verdict posted, no artifact uploaded, no stub-retry, and no quota-skip --- because steps 11 and 12 are gated on steps.claude-review.outcome == 'success', which is exactly the chain this issue describes.

Why this case is worth adding

This issue is framed around quota exhaustion, and its suggested fix targets that path. But the mechanism has nothing to do with quota: any hard failure of step 10 skips the guard, and therefore skips stub_review detection, quota_exhausted detection, the execution-file upload, and the review comment together.

A 27-minute run that exits 1 is not quota exhaustion --- quota exhaustion is the fast case (total_cost_usd == 0, num_turns == 1; the earlier attempt on this same PR failed in 18s on a plugin-install error, and a stub failed in 49s). Whatever this was, it burned nearly half an hour of runner time and produced no diagnosable artifact, because the step that uploads the artifact was gated behind the step that failed.

That makes the impact wider than "the graceful skip is unreachable": the diagnostics are unreachable too. There is no execution file to inspect, so the only evidence left is the step table above.

Bearing on the suggested fix

The fix proposed here already covers this --- gating on the execution file rather than on the action's outcome, and widening exec-file's own gate the same way. Two notes from this case:

• Widening exec-file matters at least as much as widening fail-check. Without the artifact, a failure like this one leaves nothing behind to classify, so even a correct guard would have had nothing to read.
• Worth confirming the execution file actually exists after a long-running hard failure, not only after the fast quota case where the log shows Log saved to ... before the action errors. If it does not, the guard needs a path that distinguishes "no file because the run died early" from "no file because the step was skipped".

Impact right now

#357 has taken three review attempts at two heads with no verdict from this workflow: a plugin-install failure (since fixed by #359 plus the @v2 slide), a stub whose automatic retry and one manual rerun_failed_jobs both also stubbed, and now this. Its other two reviewers are independently unavailable --- Copilot has refused for quota eight times, and Jules has timed out at its 15-minute ceiling twice --- so the unreachable recovery paths here are the difference between that PR having an external verdict and not having one.

---

Generated by Claude Code

[dem-extra1]

Independent reproduction, different repo and different Anthropic account

This fired again today in UCD-SERG/serodynamics, which matters because it is a different repository, a different org, and a different Anthropic account from the 2026-07-28 outage this issue was filed from. The mechanism is not specific to one account's quota event.

Step outcomes from run 30482942947, job review / claude-review, confirming the chain exactly as this issue describes it:

#	Step	Conclusion
10	Run Claude Code Review	failure
11	Resolve and upload execution file path	skipped
12	Fail the check if the review did not complete (attempt 1)	skipped
18	Post quota-exhausted comment	skipped

Steps 11 and 12 both carry if: steps.claude-review.outcome == 'success', so the detector never ran, quota_exhausted was never written, and step 18 could not fire. The result object matched the detector's signature precisely (is_error:true, num_turns:1, total_cost_usd:0).

Root cause has since been confirmed by the account owner: the account was out of quota, resetting 1pm PT 2026-07-30. So this was a textbook instance of the case the graceful skip exists for, and it presented as an opaque red check instead.

What it cost, concretely

This is the part worth adding to the issue's argument for priority. Because the check reported only the generic "did not complete successfully and was not eligible for a stub-review retry", diagnosing it consumed a full session: filing serodynamics#281 against the wrong hypothesis (an expired CLAUDE_CODE_OAUTH_TOKEN), a Settings check to rule out an unset secret, and an attempt to surface the hidden SDK error with show-full-output that could not work (see below). The intended one-line warning --- "Claude review skipped --- CLAUDE_CODE_OAUTH_TOKEN quota or auth error (zero cost, turn 1). Re-trigger the review once the quota resets." --- would have ended it immediately.

One adjacent finding, so it does not get conflated with this bug

Trying to enable show-full-output from a branch produces a different skip that is not this issue:

##[warning]Skipping action due to workflow validation: Workflow validation failed.
The workflow file must exist and have identical content to the version on the
repository's default branch.

claude-code-action requires the running workflow file to be byte-identical to the default branch's copy, so editing the caller to add a diagnostic flag makes the action skip before the model is called, producing no execution output at all rather than a zero-cost result object. Practical consequence for anyone debugging this class of failure: show-full-output cannot be tested from a branch, only from main. Distinguishing the two is easy --- this issue's case has an execution file, that one does not.

---

Generated by Claude Code