You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Claude Code action terminal result envelope: is_error: true, duration_ms: 35770, num_turns: 12, total_cost_usd: 0.2947491, permission_denials_count: 1.
The postrun step (assert-run-healthy.mjs) logged: 'Claude API overloaded (HTTP 529) — transient; re-run with back-off (attempt 1). Use Re-run failed jobs in the Actions UI; .github/actions/mesh-retry-backoff adds jitter delay.'
The run's own .github/actions/mesh-retry-backoff step (initial jitter) executed but was a no-op on this attempt (attempt 1), so no back-off delay preceded the overloaded call.
Classifier reasoning (src/dev-mesh/classify.js)
Precedence: infra > out-of-scope > flake > real_bug.
extractSignals matches INFRA_RE directly on the literal strings HTTP 529 / api overloaded present in the job log, giving infraError: true. classifyFailure returns infra_auth at the first precedence branch (infraError true -> INFRA_AUTH, auth/infra signature in log), before any out-of-scope/flake/real_bug check runs. This is not a code bug — there is no diff to relate it to; this is the mesh's own scheduled automation (dev-mesh-triage) hitting a transient Anthropic API capacity condition. Same class as the prior precedent issues (#385, #418, #456, #482, #816, #850).
The one permission_denials_count: 1 in the result envelope is unrelated noise from the Triager's own bounded toolset (Read,Grep,Glob,Bash(gh:*)) — not the cause of the is_error (the 529 signature is the direct cause).
Current status: self-resolved
No other scheduled dev-mesh workflow run on 2026-07-30 shows a matching failure — dev-mesh-ci-sweep (06:13), dev-mesh-intake (06:08 and 09:15), dev-mesh-security (09:16), and every other dev-mesh-* run before and after 06:38 completed with conclusion: success. Hermetic CI (ci.yml) and the nightly integration pipeline are both green on main; no open PR (#779, #772, #769, #495) has a failing check. This was an isolated single-run blip, not a cluster.
What a human should do
No action required to unstick anything — surrounding scheduled runs (before and after) are green, so this did not block any other automation.
If HTTP 529s recur/cluster, check the Anthropic status page for an ongoing capacity incident.
Triager classification
Label: infra_auth
Action: Escalate to human — do NOT re-kick, do NOT attempt a code fix.
Evidence
One dev-mesh-triage scheduled check run failed today (2026-07-30):
The Claude Code action terminal result envelope: is_error: true, duration_ms: 35770, num_turns: 12, total_cost_usd: 0.2947491, permission_denials_count: 1.
The postrun step (assert-run-healthy.mjs) logged: 'Claude API overloaded (HTTP 529) — transient; re-run with back-off (attempt 1). Use Re-run failed jobs in the Actions UI; .github/actions/mesh-retry-backoff adds jitter delay.'
The run's own .github/actions/mesh-retry-backoff step (initial jitter) executed but was a no-op on this attempt (attempt 1), so no back-off delay preceded the overloaded call.
Classifier reasoning (src/dev-mesh/classify.js)
Precedence: infra > out-of-scope > flake > real_bug.
extractSignals matches INFRA_RE directly on the literal strings HTTP 529 / api overloaded present in the job log, giving infraError: true. classifyFailure returns infra_auth at the first precedence branch (infraError true -> INFRA_AUTH, auth/infra signature in log), before any out-of-scope/flake/real_bug check runs. This is not a code bug — there is no diff to relate it to; this is the mesh's own scheduled automation (dev-mesh-triage) hitting a transient Anthropic API capacity condition. Same class as the prior precedent issues (#385, #418, #456, #482, #816, #850).
The one permission_denials_count: 1 in the result envelope is unrelated noise from the Triager's own bounded toolset (Read,Grep,Glob,Bash(gh:*)) — not the cause of the is_error (the 529 signature is the direct cause).
Current status: self-resolved
No other scheduled dev-mesh workflow run on 2026-07-30 shows a matching failure — dev-mesh-ci-sweep (06:13), dev-mesh-intake (06:08 and 09:15), dev-mesh-security (09:16), and every other dev-mesh-* run before and after 06:38 completed with conclusion: success. Hermetic CI (ci.yml) and the nightly integration pipeline are both green on main; no open PR (#779, #772, #769, #495) has a failing check. This was an isolated single-run blip, not a cluster.
What a human should do
Filed by the Triager (dev-mesh-triage sweep)