[safe-output-health] Safe Output Health Monitor - 2026-08-03: PR Sous Chef head-ref hard-fail plus Code Scanning Fixer patch-size cap stuck recurring

[github-actions[bot]]

Executive Summary

This audit covers 2026-08-02T12:41:55Z to 2026-08-03T05:07:51Z (~16.4h, a partial-day lower bound; the logs pull hit its 300-run cap before spanning the full 24h window). Across 258 runs, this audit found 4 confirmed in-scope safe-output ("Process Safe Outputs") hard failures, all on scheduled workflows. Critically, all 4 were mistagged driver_exit in the upstream master log summary (implying an out-of-scope agent-container crash), when in fact each runs agent job succeeded and only the safe_outputs job failed - reconfirming and extending the 2026-08-02 methodology-correction finding that the failure_kind tag cannot be trusted at face value.

Methodology upgrade this audit: rather than spot-checking a handful of driver_exit-tagged runs, this audit Grep-swept all 268 locally-cached run_summary.json files for job_details[] entries named safe_outputs with conclusion failure, independent of the run-level tag - effectively a complete sweep of the captured window rather than a sample. Two control-check runs (PR Code Quality Reviewer) confirmed the tag is still usually accurate - the mistagging is specific to runs where safe_outputs itself fails after a successful agent job, not universal.

One finding is new and fully root-caused for the first time (update_pull_request "head ref does not exist" on PR Sous Chef); one is a confirmed identical recurrence from 2026-08-01 (Code Scanning Fixer patch-size cap), proving that cluster is now a stuck daily-failing job rather than a one-off. The long-standing review_path_unresolved_422 Path-variant remains unvalidated for another consecutive audit - this window was fully read-only (0 safe items written across all 258 runs), so no PR-review activity occurred to exercise it either way.

Safe Output Job Statistics

Metric	Value
Runs in captured window	258
Window coverage	~16.4h (partial-day lower bound)
Confirmed in-scope safe_outputs hard failures	4
Runs mistagged driver_exit upstream (of the 4)	4 (100%)
Control-check runs confirming tag IS still usually accurate	2
Total safe-output items written this window	0 (fully read-only window)
Engines active	copilot: 154, claude: 57, pi: 44, codex: 3

Error Clusters

1. pr_sous_chef_update_pull_request_head_ref_missing (NEW - fully root-caused)

3 occurrences, all PR Sous Chef (pi engine, schedule event):

• §30764198337 - PR Sous Chef Fix markitdown MCP configuration to use correct npm package #2302 - PRs Require explicit repo for wildcard push_to_pull_request_branch targets in multi-repo workflows #49813 and Add first-class agent job gating via jobs.agent.needs and jobs.agent.if #49814 both hard-failed (Failed: 2)
• §30755002904 - PR Sous Chef [ca] Update CLI Versions: Claude Code 2.0.26, Copilot 0.0.350, Codex 0.48.0 #2294 - PR Fix evals AIC rendering in generated no-op footers #49802 hard-failed (Failed: 1)
• §30751969165 - PR Sous Chef OpenID support #2291 - PR Update python:alpine container pin to remediated digest in action/workflow lock data #49791 hard-failed (Failed: 1)

Exact error text (recovered for the first time this audit)

[warning] Failed to update pull request 49813 branch from base: ERR_API update pull request 49813 branch from base failed (attempt 1)
Original error: head ref does not exist - https://docs.github.com/rest/pulls/pulls update-a-pull-request-branch
[error] Failed to update pull request 49813: ERR_API update pull request 49813 failed (attempt 1)
[error] Message 1 (update_pull_request) failed: ERR_API

Root cause: PR Sous Chef targets Copilot-coding-agent-authored PRs whose head branches are ephemeral and can be deleted or force-pushed between the triggering comment and this scheduled runs update_pull_request (branch-from-base) call. GitHubs update-branch endpoint then returns head ref does not exist.

Notable inconsistency: in run 30751969165, PR #49762 hit the identical head ref does not exist condition in the same batch but was logged non-fatal and did not fail the run - while PR #49791 (same run, same condition) hard-failed. A non-fatal code path for this exact error already exists somewhere in the handler; it is just not applied uniformly.

2. code_scanning_fixer_patch_size_exceeds_max_patch_size_config (RECURRED - confirmed identical to 08-01)

1 occurrence this window, §30776690621 - Code Scanning Fixer #745 (schedule):

Patch size: 41422 KB (maximum allowed: 4096 KB)
[error] Message 1 (create_pull_request) failed: Patch size (41422 KB) exceeds maximum allowed size (4096 KB)

This is the exact same patch size (41422 KB) on the exact same fix (Remove committed actionlint/gosec binaries from git history) as the run first documented on 2026-08-01 (run 30714466597). This confirms the scheduled job is stuck, re-generating and re-failing on an identical oversized patch every run - not a one-off. Root cause is a task/config mismatch: removing large committed binaries from git history inherently produces a diff on the order of the binaries size (tens of MB), which will always exceed the 4 MB max_patch_size cap.

Root Cause Analysis

Both confirmed clusters share a common theme: the handler already has correct behavior for the failure condition somewhere in the codebase, but does not apply it consistently or does not check for it proactively.

• PR Sous Chef: a non-fatal path for head ref does not exist exists (observed for PR feat: shellcheck linting phase for run steps in compile pipeline #49762) but is not used for all PRs hitting the same condition.
• Code Scanning Fixer: there is no dedup/backoff, so an unfixable-under-current-config patch gets regenerated and re-submitted daily with 100% predictable failure.

Separately, this audit reconfirms the upstream tag-reliability gap: 4/4 in-scope failures this window were mistagged driver_exit, meaning any downstream consumer trusting that tag without cross-checking job_details[].safe_outputs.conclusion would have reported zero in-scope safe-output incidents this window instead of 4.

Recommendations

Immediate actions:

1. Apply PR Sous Chefs existing non-fatal handling for head ref does not exist (proven working on PR feat: shellcheck linting phase for run steps in compile pipeline #49762) uniformly to all update_pull_request branch-from-base calls - a consistency fix, not new logic.
2. Add attempt dedup/backoff to Code Scanning Fixer for alerts whose last create_pull_request attempt failed on patch-size - it is currently burning a scheduled run daily on a guaranteed-identical failure.

Config changes:
3. Either raise max_patch_size for large-binary-removal alert classes in Code Scanning Fixer, or have the agent redirect to a descriptive issue/comment instead of a direct PR when the estimated diff would exceed the cap.

Process improvements:
4. Do not trust the summary-level failure_kind tag for safe-output health monitoring; cross-check job_details[].safe_outputs.conclusion per run, as this audit and the 2026-08-02 audit both had to do manually.

Work item plan:

• P0: PR Sous Chef update_pull_request non-fatal-classification consistency fix (small, root cause understood, prior working example exists).
• P0: Code Scanning Fixer patch-size dedup/backoff (small, prevents daily guaranteed failure).
• P2: max_patch_size policy decision for binary-removal alert classes (needs maintainer input on desired behavior).

Historical Context

• pr_sous_chef_update_pull_request_head_ref_missing is a new, precisely-identified sub-signature within the standing pr_sous_chef_scheduled_add_comment_update_pull_request_no_triggering_context family first seen 2026-07-23/07-24 - this is the first audit to recover the exact error text for this family rather than inferring from step pass/fail alone.
• code_scanning_fixer_patch_size_exceeds_max_patch_size_config was first identified 2026-08-01 (run 30714466597) and has now recurred identically, confirming it is an ongoing stuck condition rather than a one-off.
• review_path_unresolved_422 (Path-variant) remains unvalidated for another consecutive audit - the recovery code path at pr_review_buffer.cjs:554 has still never fired in production since the 2026-05-27 regression, but this window offered no PR-review activity at all to exercise it (0 safe-output items written across the entire 258-run window).
• The failure_kind driver_exit tag-reliability gap, first documented 2026-08-02, is reconfirmed: 100% of in-scope failures this window were mistagged.

Metrics/KPIs

KPI	This window	Note
In-scope safe_outputs hard failures	4	up from 0 confirmed clean days (08-01), matching 08-02s finding of 7 (different clusters)
Tag-mistagging rate among in-scope failures	100% (4/4)	reconfirms 08-02 finding (7/12 that day)
Safe-output items written	0	fully read-only window - no write-capable activity to assess handler health on the happy path
Recurring clusters newly recurred	1 (Code Scanning Fixer, identical patch)	confirms stuck status

Next Steps

• Track whether the PR Sous Chef and Code Scanning Fixer fixes land; re-verify against future scheduled runs.
• Continue monitoring for a write-rich window to re-test review_path_unresolved_422 Path-variant.
• Cache-memory updated: 2026-08-03.json, index.json, error-patterns.json, recurring-failures.json, solutions.json.

References:

• §30764198337
• §30776690621
• §30751969165

Generated by 🔒 Safe Output Health Monitor · agent · 385.9 AIC · ⌖ 27.3 AIC · ⊞ 9.7K · ◷

• expires on Aug 3, 2026, 9:53 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-08-04T05:53:13.914Z.

Closed by Workflow