Fix PR Sous Chef's update_pull_request path so an unsigned branch-update commit no longer hard-fails the safe_outputs job — it broke twice in the last 6h.
Parent report: #47659 · Analyzed runs: §30074181699, §30068020977
Problem statement
The safe_outputs job of PR Sous Chef fails at Process Safe Outputs even though the agent job succeeds and 6/7 safe-output messages apply. The single failing message is update_pull_request on PR #47706, rejected non-retryably by branch protection. This is a different signature from #47659 (resolve_pull_request_review_thread); tracking it separately so the correct code path is fixed.
Affected workflows & run IDs
.github/workflows/pr-sous-chef.lock.yml- §30074181699 — explicit error (below)
- §30068020977 — same workflow,
safe_outputs step failed in the same window (error truncated from tail, same code path)
Exact error (run 30074181699)
1 safe output(s) failed:
- update_pull_request: ERR_API: update pull request #47706 failed (attempt 1)
Original error: ERR_API: update pull request #47706 branch from base failed (attempt 1)
Original error: Repository rule violations found
Commits must have verified signatures.
- https://docs.github.com/rest/pulls/pulls#update-a-pull-request-branch
Retryable: false
Processing Summary: Total 7, Successful 6, Failed 1 → job exits non-zero.
Probable root cause
The update_pull_request handler calls the update-branch-from-base API, which creates a merge commit authored by the workflow token/GitHub App. The repo enforces a "Commits must have verified signatures" ruleset, and that commit is unsigned, so GitHub rejects it as a non-retryable rule violation. Because the processor counts any failed message as a job failure, the whole safe_outputs job goes red despite all user-visible outputs succeeding.
Proposed remediation (pick one; first is lowest-risk)
- Degrade gracefully: treat a non-retryable
Repository rule violations / "verified signatures" error from update-branch-from-base as a soft warning — log it, drop that single message, and do not fail the safe_outputs job when all other messages succeeded.
- Guard the branch-update: skip the update-branch-from-base call when the target repo enforces verified signatures (detect via ruleset/branch-protection lookup), updating only PR metadata.
- Sign the commit: have the update-branch operation produce a verified/signed commit (GitHub App commit signing) so the ruleset is satisfied.
Success criteria / verification
- A PR Sous Chef run where
update_pull_request targets a PR on a verified-signatures-protected branch completes with safe_outputs green (or a clearly-labeled soft warning), and the other messages still apply.
- Re-run against a repo with the ruleset enabled: no
##[error]1 safe output(s) failed for this cause; step summary shows the message skipped/warned rather than failed.
References: §30074181699, §30068020977
Related to #47659
Generated by 🔍 [aw] Failure Investigator (6h) · age00 · 118.3 AIC · ⌖ 34.2 AIC · ⊞ 5.2K · ◷
Fix PR Sous Chef's
update_pull_requestpath so an unsigned branch-update commit no longer hard-fails thesafe_outputsjob — it broke twice in the last 6h.Parent report: #47659 · Analyzed runs: §30074181699, §30068020977
Problem statement
The
safe_outputsjob of PR Sous Chef fails at Process Safe Outputs even though the agent job succeeds and 6/7 safe-output messages apply. The single failing message isupdate_pull_requeston PR #47706, rejected non-retryably by branch protection. This is a different signature from #47659 (resolve_pull_request_review_thread); tracking it separately so the correct code path is fixed.Affected workflows & run IDs
.github/workflows/pr-sous-chef.lock.ymlsafe_outputsstep failed in the same window (error truncated from tail, same code path)Exact error (run 30074181699)
Processing Summary: Total 7, Successful 6, Failed 1 → job exits non-zero.
Probable root cause
The
update_pull_requesthandler calls the update-branch-from-base API, which creates a merge commit authored by the workflow token/GitHub App. The repo enforces a "Commits must have verified signatures" ruleset, and that commit is unsigned, so GitHub rejects it as a non-retryable rule violation. Because the processor counts any failed message as a job failure, the wholesafe_outputsjob goes red despite all user-visible outputs succeeding.Proposed remediation (pick one; first is lowest-risk)
Repository rule violations/ "verified signatures" error from update-branch-from-base as a soft warning — log it, drop that single message, and do not fail thesafe_outputsjob when all other messages succeeded.Success criteria / verification
update_pull_requesttargets a PR on a verified-signatures-protected branch completes withsafe_outputsgreen (or a clearly-labeled soft warning), and the other messages still apply.##[error]1 safe output(s) failedfor this cause; step summary shows the message skipped/warned rather than failed.References: §30074181699, §30068020977
Related to #47659