push_to_pull_request_branch: size checks count base-branch changes merged into the PR branch #68448

Summary

With push-to-pull-request-branch configured for patch-format: bundle and signed-commits: false, an agent can merge the base branch into the PR branch (for example to resolve a conflict) and the merge commit is preserved — the docs say signed-commits: false "can preserve merge commits". But the handler's two size checks measure against the old PR head, so everything the merge brings in from the base branch is counted as the agent's change. On a busy repository the push is rejected as soon as the branch is about a day behind, and max-patch-size cannot be raised past the schema maximum of 10240 KB.

Where

Seen on v0.89.21; the same code is in v0.91.10 and current main (actions/setup/js/push_to_pull_request_branch.cjs):

1. Patch preview size (~L477-514): the uncompressed patch is git format-patch <old PR head>..<tip> (generate_git_patch.cjs), which includes every base-branch commit reachable from the merge.
2. Changed content size (~L1296-1307): git diff --name-only <rangeBaseRef>..HEAD with rangeBaseRef = the remote PR head before apply, then the full working-tree size of each listed file (getChangedBlobSizeBytes). Every file the base branch changed since the PR forked is counted at full size.

Impact (measured)

On one repository, 67 open agent PRs were each checked against the current base branch: if they merged it now, the changed-content check would exceed 10240 KB for 30 of them (already at ~0.9 days behind), and the patch-preview check for 10. So in practice an agent cannot resolve a base-branch conflict on a PR older than about a day.

Background

I understand why agent-supplied diff_size is no longer trusted (#28198 introduced it, #51133 removed it; the spec says the handler MUST ignore agent-supplied diff_size). The base-branch part, however, can be excluded from trusted state the handler already has: it fetches the remote refs itself, and generate_git_bundle.cjs already excludes ^origin/<default branch> when building the bundle.

Suggestion

When the candidate head contains the base branch tip that the handler fetched itself, measure both checks over the agent's own change instead of <old PR head>..<new head> — for example against a baseline that already includes that base tip (the old PR head merged with it), so that only content the agent wrote is counted. A conflict resolution then counts as agent content, while unmodified base-branch changes do not. Alternatively, a documented option that selects this baseline.

Related: the agent-facing text for this tool (safe_outputs_push_to_pr_branch.md) says "Do NOT use git merge … Use git rebase instead", while the same tool is append-only and does not force-push, so a rebased branch cannot be published; with signed-commits: false the merge is the only workable route, and the guidance could say so.

Our workaround

We patch the installed handler at job start so that, when the candidate newly incorporates the workflow's own GITHUB_SHA (the trusted base commit that dispatched the run), the size and protected-file checks compare that commit with the candidate. We would like to drop this patch.