Hi Graphite team! We seem to occasionally hit an issue when pushing multiple branches in a stack - some PRs don't run the required CI checks and are stuck permanently "Expected — Waiting for status to be reported", and we couldn't manually rerun the checks either. The only way to get out of this bad state seems to be making some edits and pushing again. We use the exact setup from graphite.com/docs/setup-recommended-ci-settings#…:

on:
  pull_request:
    types: [opened, reopened, synchronize]
    branches-ignore:
      - "**/graphite-base/**"

Our theory (to be 100% transparent, with the help of Claude) is: during a stack resubmit, Graphite does (per PR): retarget base to

graphite-base/N

→ force-push the rebased head → retarget base back. The force-push happens while the base is still

graphite-base/N

, so if GitHub evaluates the synchronize event inside that window, the workflow is filtered out by branches-ignore (which matches on the base branch). The retarget-back a few seconds later only fires edited, which isn't a trigger type per the recommended config — so no CI run is ever created for the new head SHA, and required checks sit at "Expected" forever.

following, i also frequently have this issue. it also happens when changing PR order or changing parent branch/etc

Hey There! During stack submit/reorder we retarget onto

graphite-base/*

, the force-push can land first, and

synchronize

gets filtered by the recommended

branches-ignore

. Retarget-back is only

edited

, so checks never start. Can you try this workaround? Create a tiny no-op commit / re-push once the base is the real parent. If that doesn't work can you provide me a PR link so I can review? Thanks!

yeah the workaround fixes it, but it's a bit annoying experience

This is a good callout. Restack/submit can re-park upstack on

graphite-base/*

and the same skip hits the next PRs. After the no-op, from the bottom try

gt submit --stack

(or

gt ss

) so descendants aren't parked mid-push. Still annoying; I'm passing the restack-cascade feedback along internally. No ETA to relay but once we have a resolution I will double back and alert you. Thanks!

Thanks. I understand there's some Github API limitation tricky to work around : )