[aw-failures] PR Sous Chef: `update_pull_request` with `update_branch: true` fails workflow on benign GitHub API responses

[github-actions]

Summary

The PR Sous Chef scheduled workflow has failed 2 of 7 runs in the last 6 hours. Both failures occur in the safe_outputs job after the agent has finished its useful work. The root cause is that the update_pull_request safe-output handler (configured with update_branch: true) treats two benign GitHub API responses as hard errors and fails the entire workflow run.

Affected workflow

• PR Sous Chef (scheduled, main)
• Failure rate (last 6h): 2/7 = 29%

Failed runs analyzed

Run	Time	Failure mode	Affected PRs
§25892817484	2026-05-15T00:06Z	There are no new commits on the base branch	#32223
§25889685241	2026-05-14T22:38Z	merge conflict between base and head	#32213, #32220

In both cases the agent and detection jobs succeeded; only the post-agent safe_outputs job failed.

Probable root cause

When update_pull_request is invoked with update_branch: true, the handler calls the GitHub REST endpoint PUT /repos/{owner}/{repo}/pulls/{number}/update-branch. GitHub returns 4xx responses in two non-actionable scenarios:

1. There are no new commits on the base branch. — the PR branch is already up to date. This is a benign no-op.
2. merge conflict between base and head — the PR cannot be auto-updated because of a real conflict; this requires human resolution but is not an agentic-workflow defect.

In both cases the handler currently:

• emits a ##[warning] for Failed to update pull request #N branch from base
• then emits a hard ##[error] for the message, marking the message as failed
• then emits ##[error]N safe output(s) failed: and the safe_outputs job exits non-zero

The workflow run is reported as failed even though the agent already posted its sous-chef comments successfully and the underlying GitHub state is unchanged.

Evidence — run 25892817484 (no-new-commits)

##[warning]Failed to update pull request #32223 branch from base: ERR_API:
  update pull request #32223 branch from base failed (attempt 1)
  Original error: There are no new commits on the base branch.
  Suggestion: This error cannot be resolved by retrying.
##[error]Failed to update pull request #32223: ERR_API: update pull request #32223 failed (attempt 1)
##[error]✗ Message 1 (update_pull_request) failed
Failed: 1
##[error]1 safe output(s) failed:
  - update_pull_request: ERR_API: ... There are no new commits on the base branch.

Evidence — run 25889685241 (merge-conflict, 2 PRs)

##[warning]Failed to update pull request #32213 branch from base: ERR_API:
  Original error: merge conflict between base and head
##[error]Failed to update pull request #32213: ERR_API: ...
##[warning]Failed to update pull request #32220 branch from base: ERR_API:
  Original error: merge conflict between base and head
##[error]Failed to update pull request #32220: ERR_API: ...
Failed: 2
##[error]2 safe output(s) failed:
  - update_pull_request: ... merge conflict between base and head
  - update_pull_request: ... merge conflict between base and head

Audit-diff: failed [§25892817484](https://github.com/github/gh-aw/actions/runs/25892817484) vs success [§25890788384](https://github.com/github/gh-aw/actions/runs/25890788384)

• Agent metrics: 13 turns / 347K tokens (failed) vs 35 turns / 652K tokens (success) — both within normal range
• MCP tool usage: no anomalies; failed run did not need an add_comment (different PR set)
• Firewall: no new/removed/blocked domains; only volume change on api.githubcopilot.com:443 (+147%)
• Conclusion: no agent regression; failure is isolated to the safe_outputs handler's response classification

Proposed remediation

Update the update_pull_request safe-output handler so that GitHub update-branch failures with these specific signals are treated as warnings rather than errors, and do not count toward the Failed: total that fails the safe_outputs job:

1. There are no new commits on the base branch. — log as info/warning, treat the operation as a successful no-op.
2. merge conflict between base and head — log as warning, optionally surface as an add_comment on the affected PR ("branch update skipped: merge conflict"), but do not fail the workflow. The branch-update step is best-effort.

Related config (from run logs):

"update_pull_request": {
  "allow_body": true,
  "allow_title": false,
  "default_operation": "append",
  "max": 10,
  "target": "*",
  "update_branch": true
}

The relevant code path is the safe-output processor that emits Failed to update pull request #N branch from base followed by Message N (update_pull_request) failed. The classifier should distinguish between:

• Hard errors (auth, rate limit, malformed payload) — should fail
• Soft conditions (no new base commits, merge conflict on update-branch) — should warn and continue

Success criteria

• A new PR Sous Chef run that triggers either failure mode (no-new-commits or merge-conflict on update-branch) finishes with conclusion: success.
• The safe_outputs job exits 0 even when one or more update_pull_request messages return GitHub update-branch soft failures.
• A warning is still surfaced in the workflow log and (optionally) as a PR comment so maintainers know the branch update was skipped.

Notes / context

• Closed issue #32040 addressed a different update_pull_request problem (Copilot CLI emitting wrong field names: pr_number vs pull_request_number). The current failures are not field-name related — the handler accepts the payload, calls GitHub, and then mis-classifies the response.
• No open agentic-workflows failure-tracker issue exists for this cluster.

References:

• Failed run 1: (https://github.com/github/gh-aw/actions/runs/25892817484)
• Failed run 2: (https://github.com/github/gh-aw/actions/runs/25889685241)
• Baseline successful run: (https://github.com/github/gh-aw/actions/runs/25890788384)

Generated by 🔍 [aw] Failure Investigator (6h) · ● 15.4M · ◷

• expires on May 22, 2026, 1:36 AM UTC