Skip to content

[aw-failures] [aw] Failure Investigator Report — 2026-08-18 19:00 UTC (6h) #53804

Description

@github-actions

Executive summary

Fix the malformed-JSON crash in PR Sous Chef's safe_outputs job first — it kills the job on every single trigger and accounts for 18 of the 24 failed runs (75%) in this window. Root cause is pinned to one line of generated YAML; no existing issue tracks it. Everything else this window is a single-occurrence, lower-severity blip already covered by prior reports.

24 failed runs in the last 6h → 1 confirmed new P0 (18 runs, one root cause), 4 singleton P2/likely-tracked blips, 0 issues closed (no fresh disconfirming evidence found for any of the 9 open agentic-workflows issues checked).

Failure cluster table

Cluster Severity Workflow Runs Representative Comparator Signature Status
A P0 PR Sous Chef 18/24 §32171918501 §32170093369 (identical crash, prior run) safe_outputs job crashes at startup: ERR_VALIDATION: Handler manager failed: ERR_PARSE: Failed to parse GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG New gap — no tracking, fix below
B P1 Scout 2/24 §32153071114 §32152602055 Start MCP Gateway step fails Likely matches #53191 (MCP Gateway digest-pin) — not re-verified this window
C P1 Architecture Guardian, Linter Miner 2/24 §32147417635 §32166116673 Execute GitHub Copilot CLI step fails Likely matches #52253 (Copilot proxy port 10002 refusals) — not re-verified this window
D P2 Daily Fact 1/24 §32147275242 Check KVM availability for docker-sbx fails Single occurrence, no action taken
E P2 Super Linter Report 1/24 §32146482329 Run super-linter step fails Single occurrence, no action taken

Evidence

Cluster A — malformed JSON crashes PR Sous Chef's safe_outputs job on every run (P0)

What happens: every recent PR Sous Chef run completes its agent job successfully, then the safe_outputs job dies immediately with:

##[error]ERR_VALIDATION: Handler manager failed: ERR_PARSE: Failed to parse GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG: Expected ',' or '}' after property value in JSON at position 200 (line 1 column 201)

Confirmed identically in 5 sampled runs spanning the full 6h window (§32171918501, §32170093369, §32168627250, §32167555737, §32166311424); near-certain for the remaining 13 PR Sous Chef failures since the bug is a deterministic code-generation defect, not a flaky condition.

Root cause, pinned: .github/workflows/pr-sous-chef.lock.yml:2566 embeds the allow-list as a quoted JSON string:

\"allowed_pull_requests\":\"${{ needs.approval_allowlist.outputs.eligible_pull_request_numbers }}\"

eligible_pull_request_numbers (lock.yml:1515) is produced by jq -c '[.prs[]?.number | tostring]', i.e. it already renders as a JSON array string like ["53698","53725"]. GitHub Actions splices that text in verbatim with no re-escaping, so the surrounding quotes collide with the array's own quotes and the JSON breaks exactly at allowed_pull_requests (verified locally: parsing the captured config text reproduces the same "expected ',' or '}'" error).

Compiler-side, the culprit is AddTemplatableStringSlice in pkg/workflow/compiler_safe_outputs_builder.go:63-75: when a field's value is a single-element slice matching ${{ ... }} (isExpression, pkg/workflow/expression_patterns.go:95), it stores the raw expression as a scalar string, which json.Marshal then wraps in quotes — safe only when the expression's runtime value is a plain scalar. It silently breaks for any expression whose output is itself JSON (arrays, objects), which is exactly what eligible_pull_request_numbers is. approve_workflow_run.cjs's parseAllowedPullRequests (actions/setup/js/approve_workflow_run.cjs:36-49) already expects a real array or bracket-string, so this is a pure emission bug, not a consumer bug.

Blast radius: because the crash happens before create_issue's own close_older_issues/group_by_day dedup logic ever runs, PR Sous Chef's separate "Failed jobs" auto-notifier has created 30+ open, undeduplicated [aw] Failed jobs: PR Sous Chef issues (#53245#53802) since ~2026-08-17. These will keep multiplying every ~15–20 min until the emission bug is fixed. Not closing them here — they self-expire (each carries a 7-day expiry checkbox) and closing them individually would blow the update_issue budget for no lasting benefit; fixing the root cause stops the flood at the source.

Existing issue correlation

  • Searched is:issue label:agentic-workflows state:open (9 issues) plus a targeted ERR_PARSE / allowed_pull_requests / SAFE_OUTPUTS_HANDLER_CONFIG search — no open issue covers this crash. [aw-failures] safe_outputs job hard-fails entire batch on one non-retryable error #53263 ("safe_outputs job hard-fails entire batch on one non-retryable error") is the closest by keyword but describes a different failure mode (a valid per-item API error propagating as a job failure, not a JSON parse crash before any item is processed) — not a match, left open.
  • [aw-failures] [P1] PR Sous Chef: Start DIFC Proxy step fails with no captured root cause #52502 ("PR Sous Chef: Start DIFC Proxy step fails") is a different step, different (unrelated, single-occurrence) failure from 2026-08-13 — left open, no fresh evidence either way.
  • No issues closed this round: none of the 9 open agentic-workflows issues had disconfirming evidence surface in this window's data.

Fix roadmap

Sub-issues created

  • #aw_fixp0 — Fix malformed JSON emission for approve_workflow_run.allowed_pull_requests in the safe-outputs config builder (linked as sub-issue of this report).

References:

Generated by 🔍 [aw] Failure Investigator (6h) · agent · 165.4 AIC · ⌖ 12.6 AIC · ⊞ 5.9K ·

  • expires on Aug 25, 2026, 11:15 AM UTC-08:00

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions