I'm following the recommendation from: https://graphite.com/docs/troubleshooting#why-are-my-actions-running-twice But noticing that sometimes on a stack with multiple PRs, after back to back stack updates, some of the PRs' workflows get cancelled and when I check the reason for cancellation, I see the following in github UI:

Canceling since a higher priority waiting request for org/repo-PR Checks and Deployments-refs/pull/1723/merge- exists

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

@Gareth Brickman Our team runs into this issue constantly and it's pretty maddening. In a stack of 3+ PRs, I'd say we have at least one PR have one of the runs get canceled ~80% of the time. It's bad enough that right now we're having AI auto-restart canceled workflows. Details for us:

group: ${{ github.workflow }}-${{ github.event.pull_request.number || ( github.ref == 'refs/heads/main' && github.sha || github.ref ) }}

I had LLM look at one of the cases, they found the two pushes were submitted basically at the same time, and it seems like the GitHub UI ends up confused

hey Andrew, in your workflow are you using the

concurrency

block as in the docs example? Ultimately these CI checks and the UI you're showing there is GitHub's system so it's on them for controlling the concurrency of workflows and jobs

block we use:

concurrency:
  group: ${{ github.repository }}-${{ github.workflow }}-${{ github.ref }}-${{ github.ref == 'refs/heads/main' && github.sha || ''}}
  cancel-in-progress: true

Also having this same issue, also have

cancel-in-progress: true

in my concurrency block, also getting the exact error message. It seems to randomly affect one of the PRs in a large stack, doesn't seem consistent. Seems like maybe George here , Andrew as above, myself, Marc here may all be experiencing related issues Following this thread for updates in case any of us find a resolution

Hey all, I figured this would be a nonstarter from Graphite's end, and GitHub has bigger fish to fry (i.e. outages), so I put together a GitHub action on the marketplace to auto-restart checks that are cancelled by

cancel-in-progress

in the stacked PRs context. We've been running it locally for a couple weeks and it works like a dream. The code is relatively simple. Essentially, when the two "duplicate" workflow runs are produced, GitHub UI will consistently display the one with the higher ID. But, the

cancel-in-progress

may cancel either one, so sometimes you're left with the

higherIdRun

canceled and it shows up as canceled in the UI. (Interestingly, the check is still considered passing.) This workflow receives workflow events, checks to see if it needs to be restarted, and does so. Each workflow check takes < 20s, so it's quite lightweight. LMK if you find it useful!