Skip to content

PR hygiene cancels its own runs #207

Closed

Description

@CaffeinatedCoder

How does it fail?

pr-hygiene.yml runs on opened, edited, reopened, synchronize, labeled, unlabeled, with concurrency: { group: pr-hygiene-<number>, cancel-in-progress: true }. A pull request opened with its labels and body, or labelled right after the push, starts several runs within a second or two, and every run but the last is cancelled. "Labels and issue link" is a required check on main and release/5.x.

What you ran

On 2026-10-29, gh run list --workflow pr-hygiene.yml --limit 200 (runs since 2026-10-20).

What you got

152 of the 200 runs were cancelled, 47 succeeded, 1 failed. On #204 (chore/202-sqlite-cve-5.x), five runs started between 11:46:41 and 11:46:43 on 2026-10-28; four were cancelled. Up to 20 cancelled runs on one branch (claude/150-core-refuses-constraints-fcb460).

#204 is CLEAN beside its cancelled runs, so here the last run has decided the check so far. In CodoMetis.TypeKit the same workflow left pull requests BLOCKED on a cancelled run until it was re-run by hand (CaffeinatedCoder/CodoMetis.TypeKit#144). Not seen here yet, hence severity low; the cancelled runs are noise in every pull request's checks either way.

What you expected

Each event's run completes. The check takes seconds and reads only the event payload, so cancelling saves nothing. The latest run decides the check.

Proposal

Set cancel-in-progress: false, or drop the concurrency group. With a group, a newer pending run still cancels the older pending one even when cancel-in-progress is false, so measure which choice leaves no cancelled run. Without a group, runs may finish out of order: check which result GitHub keeps for a required check when an earlier payload (no labels yet) finishes after a later one. Record what was measured in the workflow's header comment. The workflow has to change on both main and release/5.x, since a pull request runs the base branch's copy merged with its own.

Done when

On a test pull request with labels and body set within a few seconds of the push, every hygiene run completes, none is cancelled, the required check ends green, and the pull request is not BLOCKED by it. Same on both lines.

Measured (2026-10-29, #208 and #209)

  • No group: every run completed, none cancelled, but runs finish in any order and the last to finish decides. A failing run of an older payload that finished after a passing one made the check FAILURE with the labels in order. Rejected.
  • Group with cancel-in-progress: false: runs go one at a time in event order, and the last event's run finishes last. A run waiting when a newer one queues is still cancelled, but it never started and leaves no check run on the commit: on fix: let every PR hygiene run complete (5.x) #208, seven runs, three cancelled waiting, four check runs, none cancelled; on fix: let every PR hygiene run complete #209, ten runs, five cancelled waiting, five check runs, none cancelled. Chosen.

So "none is cancelled" in Done when holds for the check runs the required check reads, not for the workflow runs in the Actions list.

Activity

  1. added this to the 5.6.1 milestone on Oct 29, 2026
  2. added
    bugSomething isn't working
    severity/lowCosmetic, message or documentation-level difference
    area/releaseVersioning, changelogs, release wiring
    on Oct 29, 2026
  3. CaffeinatedCoder commented on Oct 29, 2026

    @CaffeinatedCoder
    OwnerAuthor

    Fixed on release/5.x by #208 and on main by #209.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/releaseVersioning, changelogs, release wiringbugSomething isn't workingseverity/lowCosmetic, message or documentation-level difference

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions