Very often, my checks on GitHub are cancelled: and I'm already using

concurrency:
    group: ${{ github.repository }}-${{ github.workflow }}-${{ github.head_ref || github.ref }}
    cancel-in-progress: ${{ github.event_name == 'push' }}

But GitHub cancels the wrong one, and the other completes, but doesn't update my PR checks. anyone seeing this too?

(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>

asked Claude Code to investigate this for me:

Title: gt submit --stack triggers duplicate CI runs, and GitHub may bind PR status to the cancelled run

  Summary:
  When using gt submit on a stack, each PR gets two workflow runs triggered simultaneously. While the documented fix (concurrency with cancel-in-progress: true) cancels duplicates, GitHub sometimes binds the PR status check to the run that gets cancelled, causing PRs to show failed/cancelled CI status despite a successful run existing.

  Environment:
  - Graphite CLI version: [run gt --version]
  - Repository: new-gen-ai/canopy
  - CI: GitHub Actions with concurrency configured per Graphite docs

  Steps to Reproduce:
  1. Have a stack of PRs
  2. Run gt submit --stack
  3. Observe duplicate workflow runs for each PR

  Evidence:

  PR #2179 - Two runs triggered at identical timestamp 2025-12-15T13:35:11Z:

  | Run ID      | Created   | Detect Changes Started | Result    |
  |-------------|-----------|------------------------|-----------|
  | 20234135402 | 13:35:11Z | 13:35:14Z              | cancelled |
  | 20234135392 | 13:35:11Z | 13:35:21Z              | success   |

  - Run 402 (higher ID) started executing first but was cancelled
  - Run 392 (lower ID) started later and succeeded
  - GitHub bound PR status to run 402 (the cancelled one)

  This pattern occurs for every PR in the stack - not just one.

  Current Workaround:
  Using concurrency config as documented:
  concurrency:
    group: ${{ github.repository }}-${{ github.workflow }}-${{ github.ref }}
    cancel-in-progress: true

  Problem:
  The concurrency correctly cancels duplicates, but GitHub may pick the cancelled run for PR status, causing PRs to appear failed.

  Request:
  Could Graphite stagger the git push and GitHub API call slightly (even 1-2 seconds) so they don't trigger duplicate events with identical timestamps? This would let GitHub bind to a single run before any cancellation occurs.

i was thinking you had the concurrency on to reduce the amount of CI runs, which the optimizations could also do. Additionally, the CI optimizations could be set up to not run CI on these midstack PRs each time a rebase happens