Skip to content

Label sync workflows have no concurrency group and can wipe labels #2205

Description

@hickeyma

What happened:
pr-kind-label.yaml and issue-kind-label.yaml both wipe every kind/* and area/* label and then re-add from the body. Neither declares a concurrency: group, so two runs in quick successive edits can interleave partway through that sequence and leave labels matching neither edit.

Copilot spotted it reviewing #2157: #2157 (comment)

It was not fixed in #2157 because pr-kind-label.yaml already had the same bug and wanted to keep the PR for the feature separate to the bug.

What you expected to happen:
Labels match the final body after a burst of edits. Each run finishes its remove and re-add as a unit instead of getting interleaved by the next one.

How to reproduce it (as minimally and precisely as possible):

  1. Open an issue with /kind bug in the body
  2. Edit the body twice fast, so the second run starts before the first finishes
  3. Watch the two runs overlap in the Actions tab

This is timing dependent, so it won't hit every time. Same deal on pr-kind-label.yaml via pull_request_target: edited.

Anything else we need to know?:
The fix suggested by Copilot is the not the way to fix it. cancel-in-progress: true makes this worse because the cancel can land in the gap between the remove and the re-add. You end up with no kind/* labels at all. And if the newer body dropped the directive, the run that did the cancelling won't re-add them either, so they
just remain removed.

We want the queued run to wait instead of killing the one in flight. re-run-action.yml already does this:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.issue.number }}
  cancel-in-progress: false

issue-kind-label.yaml can copy that as-is. pr-kind-label.yaml wants github.event.pull_request.number. The github workflow prefix keeps the two in separate groups.

Most workflows here use cancel-in-progress: true but they are idempotent check runs where binning a superseded run costs nothing. Doesn't apply to something that mutates state in two steps.

Related to #956, where both workflows came from.

Environment:
CI only. .github/workflows/pr-kind-label.yaml and .github/workflows/issue-kind-label.yaml on main.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugCategorizes issue or PR as related to a bug.needs-triageIndicates an issue or PR lacks a triage label and requires one.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions