Make pr_labeler safe for concurrent runs

[bryanbeverly]

Why

Two labeler runs can overlap on the same PR today. The caller's concurrency group is:

group: pr-labeler-${{ github.event.pull_request.number || github.run_id }}

A workflow_dispatch backfill has no pull_request.number, so it falls back to run_id — a group of one. The documented way to label a stacked PR (gh workflow run pr-labeler.yml -f pr_number=N) can therefore run alongside an event-driven run on the same PR right now. Both bugs below are reachable without changing anything.

They also block a fix we need. Cancelling a run leaves a permanent cancelled check run on the head commit; Renovate reads every check run without discarding superseded ones (renovatebot/renovate#36837), computes a red branch status, and silently declines to automerge. Measured on one unchanged commit in truffle-release-bot#29 — five edited events from Renovate rewriting the PR body, four cancelled:

00:42:39 cancelled   00:42:43 cancelled   00:42:47 cancelled
00:42:51 cancelled   00:42:55 success (ran 22s)

cancel-in-progress: false doesn't help (only one run may be pending per group, and triggers arrive every ~4s against a ~22s job), and dropping edited isn't available (it's what applies the risk label after Bugbot edits the description).

Two fixes

1. The sticky comment converges on one copy. It's created only when no copy is found and updated thereafter, but find-then-create isn't atomic: two runs can both see "no comment yet" and both create one. Only the lowest-id copy is ever found again, so the other is orphaned permanently, showing reviewers the CODEOWNERS team list twice. The survivor is now chosen by lowest comment id and the rest are deleted — once from the listing already fetched (free, and it cleans up copies left behind before this change) and again on fresh data after a create. Choosing by id rather than by who arrived first is what makes it lock-free: concurrent runs pick the same survivor and converge instead of deleting each other's. The loser gets a 404, so deletes pass check=False.

2. A run whose inputs moved stands down. A run snapshots the PR at start and applies ~20s later. Task-list checkboxes save on click, so ticking Urgent then High complexity fires two edited events seconds apart. Run A reads the unticked body and plans a removal; run B reads it ticked but skips its add because the label is still present; A then lands the removal, and nothing re-runs to correct it. The fix re-reads the body and head sha immediately before applying and skips when either moved.

Only inputs are compared — body for risk and template labels, head sha for size and domain. Applying labels or the comment changes neither, so a run whose inputs held still always proceeds and the newest run can't be starved.

What this unlocks

Fix 2 is the ordering cancel-in-progress was providing, moved into the script. The workflow achieved it by killing the older run and leaving a red check run behind; the script now reaches the same outcome with the run exiting green. The concurrency group stops being load-bearing, so a follow-up can delete it from the callers and unblock Renovate automerge. No caller changes here.

Risk

The common single-run path is unchanged: the prune is a no-op with no API calls, and the guard costs one gh pr view per PR before applying. Dry runs skip the guard entirely (nothing to stand down from) and count duplicates without deleting.

Test plan

• python -m pytest .github/scripts — 148 passed (11 new)
• ruff check and ruff format --check clean
• Dedupe coverage: survivor stable regardless of listing order, all-but-survivor deleted, single copy untouched, delete tolerates an already-removed copy, dry run counts without deleting
• Guard coverage: unchanged inputs proceed, edited body stands down, new head commit stands down, null vs empty body is not a change
• After merge: confirm on a live PR with CODEOWNERS (topo) that the comment still renders once and labels still apply
• Then delete the concurrency block in the three callers and confirm Renovate automerges

Made with Cursor