Hey folks. Hopefully this is the correct channel 🙂 Interaction between graphite and our github actions checks is very flaky. We keep getting into a state where checks are stalling or checks that github knows are not PR blocking are being treated as blocking in gaphite. This causes lot's of extra pushes, rebases etc. I'm sure this is a configuration issue. Any advice? Cheers!

(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about: - Screenshots / debug logs / list of commands you've tried to run so far - Your workflow - Current state

Screenshot 2026-05-08 at 13.50.01.png,Screenshot 2026-05-08 at 13.50.06.png

Hey Rory, few follow up Qs for you here:

checks are stalling

Does this mean that eventually the correct status appears in graphite? Is this for the buildkite or the

type-check

? both? we should be relying on github webhook to update us on the status of the checks.

being treated as blocking in gaphite

How are you handling check requirements? classic branch protection rules (BPRs)? rulesets?

github knows are not PR blocking are

How are you validating? github showing mergable? is this for everyone or only repo/ org admins maybe? Do you have bypass actors? Are you using githubs concurrency control at all?

Does this mean that eventually the correct status appears in graphite? Is this for the buildkite or the

type-check

? both? we should be relying on github webhook to update us on the status of the checks.

It was a required check that was never triggered. Graphite seemed to believe it was in progress (although we mostly blame github for this, it seems like a long standing UX issue)

How are you handling check requirements? classic branch protection rules (BPRs)? rulesets?

Basic branch protection yes

How are you validating? github showing mergable? is this for everyone or only repo/ org admins maybe? Do you have bypass actors?

Github was showing mergeable but graphite seemed to want things that ran on the PR at one point to run again (e.g. we use cursor, it had reviewed, we'd fixed the cursor review issues, and not bothered to re-run it). This could be been conflated with the other missing required check issue.

Are you using githubs concurrency control at all?

Yes, for the required type-check we're using a per-PR check, so a new push should cancel and retrigger on the HEAD

Thanks!

It was a required check that was never triggered

This, yea, there is not much we can do here. We rely on the check suite to successfully trigger based on actions that happen to the state of the PR.

we'd fixed the cursor review issues, and not bothered to re-run it

This one im curious about. Shouldnt it run on a new version of the PR ie new SHA via commit or amendment? Otherwise im not sure there is anything wrong with your settup. I would expect BPRs to work consistently well, and new versions of the PR to trigger new CI runs. We have seen some scenarios where the check is passing in github and showing as pending in graphite which often tracks to a race condition in the github concurrency setting but that doesnt seem like the issue you are facing.

It seemed to be expecting the check. When we do a cursor review, it shows up as a merge check, runs, and finishes. My read of the graphite behaviour it can see that it once ran and ended in some non success state (I'm not sure it ever marks as success TBH), and it then expects it to re run on a new commit. We trigger this manually for our workflow.

ah got it, so you fix whatever the check calls out and dont run the check again to see if there is a new problem or it calls out a different problem. And you have the check as required? I think the way ive seen this handled most often is to have the BPR for "require all threads be resolved" and then mark the reviewer bot leave comments rather than a check.