fix(ci): stop backport PR-body updates failing on token scopes (and lying about conflicts)

[AztecBot]

What went wrong

The backport of #25159 to v5-next was reported in #backports (and on the PR) as ❌ Failed to cherry-pick to v5-next due to conflicts. There was no conflict. From the backport run:

Merge commit has multiple parents, using -m 1 for cherry-pick
Cherry-picking 0107053288759181a2f6d603663f198b7e26ab97...
Cherry-pick applied successfully!
...
Created new backport PR
Updating PR body with commit list...
Updating PR #25224 body for branch backport-to-v5-next-staging
GraphQL: Your token has not been granted the required scopes to execute this query.
The 'login' field requires one of the following scopes: ['read:org'], but your token
has only been granted the: ['repo', 'workflow'] scopes. ...
##[error]Process completed with exit code 1.

The cherry-pick succeeded, the branch was pushed and #25224 was opened. What failed was the last step — scripts/merge-train/update-pr-body.sh — because gh pr edit resolves the PR with a GraphQL query that asks for reviewer/team fields (login, name, slug). Those need read:org, and AZTEC_BOT_GITHUB_TOKEN carries only repo and workflow. Editing a PR body itself needs nothing beyond repo.

Because the whole step exited non-zero, backport.yml took the failure branch: it commented "conflicts" on the PR, pinged #backports with "conflicts", and dispatched a ClaudeBox job to go resolve conflicts that do not exist.

This is not specific to one PR. Every caller of update-pr-body.sh runs under the same token, so the same scope error is hitting merge-train and forward-port body updates too — e.g. the port-to-next-staging update in run 31789678398 failed identically a few hours earlier, and the backport-to-v5-next-staging body-update run failed again straight after. Staging PRs are left with the Body will be updated with commit list. placeholder instead of the BEGIN_COMMIT_OVERRIDE markers that drive the squashed commit message.

The fix

1. scripts/merge-train/update-pr-body.sh — set the body with gh api --method PATCH repos/{owner}/{repo}/pulls/N -f body=... instead of gh pr edit. Same REST-over-gh api style the script already uses two lines above to read base.sha/head.sha, and it needs no scope the bot token lacks. This is the root-cause fix and it covers all three callers (backport staging, port_to_next.sh, and the Merge-Train PR Body workflow).

2. scripts/backport_to_staging.sh — a body-update failure no longer fails the backport. By that point the cherry-pick has landed, the branch is pushed and the staging PR exists; the caller treats any non-zero exit as a conflict, so failing here actively misreports a successful backport. It now warns and continues. The cherry-pick conflict path writes failure_reason=conflict to $GITHUB_OUTPUT.

3. .github/workflows/backport.yml — the PR comment, the #backports message and the ClaudeBox prompt now branch on failure_reason. A real conflict reads exactly as before. Anything else says so ("not a cherry-pick conflict") and dispatches ClaudeBox to read the run log and find the real cause, rather than sending it hunting for conflicts.

Fixing the token's scopes (adding read:org) would also make gh pr edit work, but the API call doesn't need that access in the first place, so this keeps the bot token minimal.

Testing

bash -n on both scripts and a YAML parse of the workflow. The behaviour itself is only exercisable in CI: the next backport/port body update either sets the BEGIN_COMMIT_OVERRIDE markers or, if something else goes wrong, reports what actually failed. Note the changed workflow only takes effect for PRs whose base branch carries it, so v5-next keeps the old messaging until this is backported there.

---

Created by claudebox · group: slackbot · requested by Alex Gherghisan · Slack thread