Skip to content

CI watch reads a same-head run's cancelled checks as failed after a PR is labelled #927

Closed as not planned

Description

@JacobStephens2

This was generated by AI while implementing #893.

What the finding is

#893 (PR #925) adds the labeled activity type to CI's pull_request trigger, so the test:macos label starts the full macOS suite on a PR's current head. The concurrency group cancels an older CI run still in progress for the PR. With synchronize the cancelled run was on an older commit; with labeled (and reopened, already a default type) it is on the same head.

The cancelled run's unfinished jobs stay on that head as cancelled check runs, beside the new run's. GitHub::checks_on (src/github.rs:787) reads commits/{sha}/check-runs, which returns check runs of every check suite on the commit, and CI watch's reading (src/ci.rs:464-471) reads Cancelled as Failed. So a Run whose CI watch is on a PR into main when someone labels it mid-run can see failures that never happened and start a Repair.

Evidence

On PR #925, head d554e2d, test:macos was added while CI run 39537982242 was still running its Linux test job. GitHub cancelled that run and started 39539107043. Then:

gh api "repos/JacobStephens2/thirdshift/commits/d554e2d639e38ec2a50192d280be89ca6de8cbb0/check-runs?per_page=100" \
  --jq '[.check_runs[] | select(.name=="test") | {conclusion, url: .details_url}]'

listed test three times on the one head: cancelled (run 39537982242), success (an earlier probe run on the same commit) and in_progress (run 39539107043).

Why this isn't PR #925's call

#893's brief fixes both sides of the conflict: "The concurrency group and cancel-in-progress policy stay as they are", and "The factory's CI watch accepts success, neutral or skipped checks. Don't change it." Within those, the workflow can't keep the cancelled check runs off the head. PR #925 only documents the limit in docs/ci-performance.md: label a PR after its CI run has finished. Fixing it means either:

  • CI watch reading a check run as superseded when a newer run of the same workflow exists for the same head;
  • or a concurrency policy that doesn't cancel on labeled.

The Day shift has to choose which. #839 is related: it covers checks cancelled by a newer push, where the head changes; here it doesn't.

Activity

  1. added
    bugSomething isn't working
    and removed
    needs-triageMaintainer needs to evaluate this issue
    on Oct 21, 2026
  2. JacobStephens2 commented on Oct 21, 2026

    @JacobStephens2
    OwnerAuthor

    This was generated by AI during triage.

    Folded into #839. Its Agent Brief covers this same-head case alongside #839's moved Issue branch: when a workflow has more than one run on the watched head, only the most recent run's checks count. Closing this one so the fix is a single Ticket.

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

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions