ci: re-running a completed backport posts a false "Backport failed" comment on the original PR #3588

Adding a second backport label to a PR whose first backport already merged makes the bot claim the backport failed. The comment is wrong, it names a branch the change is already on, and the manual cherry-pick instructions it hands the reader do not apply. Anyone reading the PR later sees a failure sitting under a completed backport.

Clearest instance is #3119. Labeled backport on 2026-06-27, merged on 2026-06-29. Its backport to release-1.5 opened as #3127 and merged at 2026-06-30T12:47:24Z. Fifty-three seconds later, at 12:48:17Z, backport-previous was added to #3119 to also send the change to release-1.4. At 12:48:33Z the bot posted "Backport failed for release-1.5, because it was unable to cherry-pick the commit(s)." on #3119, for a branch that had held the commit for under a minute.

The re-run itself is expected and not the bug. .github/workflows/backport.yaml:5 subscribes to pull_request_target types [closed, labeled], and the backport job at :116 runs a matrix over [current, previous] guarded by which labels are present. The second label re-enters the job for both targets, so the current leg cherry-picks commits release-1.5 already has. Two of those re-runs are already harmless, because the action recognises an existing backport branch and an existing backport PR and continues quietly. The third one is not.

The mechanism is in the action, not here. git cherry-pick -x <sha> onto a branch that already contains the change is empty rather than conflicting, and git still exits 1. The action reads exit 1 as a conflict, and under the draft_commit_conflicts setting this repository passes at .github/workflows/backport.yaml:155-158 it commits the working tree with git commit --all. Nothing is staged, so that exits 1 too, the action aborts the cherry-pick and posts the conflict failure comment. I reproduced both exit codes locally against git 2.55.0. Details and line references are in korthout/backport-action#457, which is where the fix belongs.

There is a local guard worth considering while that sits open, since the false comment is cheap to prevent from this side. The action's backport branch name is deterministic, backport-${pull_number}-to-${target_branch}, so the existing Set target branch step already knows the exact head branch a previous run would have used. Asking the API whether a PR with that head exists and is merged, then dropping that target from the matrix leg when it does, skips the re-run before it can misreport. A git-side alternative is git cherry <target> <sha>, which marks a patch-equivalent commit with - and answers the same question without caring how the earlier backport was merged. Both are small. Someone closer to the release flow should pick.

A guard here does not replace the upstream fix. It only covers the case where a prior backport PR exists under this repository's own naming. The "empty cherry-pick reported as a conflict" behaviour hits every consumer of the action and belongs upstream.

What I checked:

• .github/workflows/backport.yaml:3-5 (pull_request_target, types: [closed, labeled]), :18-25 (the prepare guard reading both labels), :116-118 (the [current, previous] matrix), :144 (the action pin korthout/backport-action@0193454f0c5947491d348f33a275c119f30eb736, which is the v3.2.1 tag), :155-158 (experimental with conflict_resolution: draft_commit_conflicts).
• fix(seaweedfs): point S3 consumers at the reachable S3 service #3119: label and merge timeline via GET /repos/cozystack/cozystack/issues/3119/events, bot comment text and timestamp via /issues/3119/comments.
• [Backport release-1.5] fix(seaweedfs): point S3 consumers at the reachable S3 service #3127: mergedAt=2026-06-30T12:47:24Z, baseRefName=release-1.5, headRefName=backport-3119-to-release-1.5.
• Upstream src/git.ts cherryPick at main (:186, :229, :236, :241) and at the pinned v3.2.1 commit (:147, :186, :193, :198), plus the branch_name default in action.yml.
• Local reproduction of git cherry-pick -x exiting 1 on an already-applied commit and git commit --all then exiting 1, git 2.55.0.
• Conflict_resolution draft_commit_conflicts doesn't open draft PR on empty commit due to conflicts korthout/backport-action#457 (open) and Treat errors on repeated runs gracefully korthout/backport-action#470 (closed by the v3.2.1 work that made the branch-exists and PR-exists paths quiet).