Hi — Graphite shows "Waiting on CI…" on a PR even though GitHub considers the required check satisfied. Want to understand the readiness logic and whether there's a config we're missing. Repo: Rogo-Technologies/ask-rogo PR: https://app.graphite.com/github/pr/Rogo-Technologies/ask-rogo/33486 SHA: 64bf668a064dcf29ec586ddcbbe054f38f2295ea Setup: Socket Security: Pull Request Alerts is a required check, but during incidents Socket's app will sometimes runs ~20 min and time out. Trying to get around this 20 min wait, we post a SUCCESS commit status under the same context name from github-actions[bot], and we unpinned the app_id on the required check so any source satisfies it. Rollup for that SHA contains both: -

CheckRun

"Socket Security: Pull Request Alerts" — IN_PROGRESS (socket-security app, 173401Z) -

StatusContext

"Socket Security: Pull Request Alerts" — SUCCESS (github-actions[bot], 174301Z) GitHub: mergeable: MERGEABLE, mergeStateStatus: BEHIND (only blocker is strict-mode rebase), combined commit-status success. GitHub treats the required check as satisfied. Graphite: "Waiting on CI…" — apparently keyed off the in-progress

CheckRun

rather than the newer SUCCESS

StatusContext

under the same name. Questions: 1. When the rollup has two same-named entries (in-progress

CheckRun

+ newer SUCCESS

StatusContext

), how does Graphite decide readiness? Does it mirror GitHub's most-recent-wins logic or block on any matching in-progress

CheckRun

? 2. Is there a setting (Graphite Protections or otherwise) to tell Graphite which rollup entries to ignore — e.g. exclude

CheckRuns

from a specific app? 3. Any difference here between rulesets and legacy branch protection? Repro steps: 1. On a repo with a required status check named X (originally posted by App A). 2. Unpin the app_id on X via PATCH /repos/.../branches/main/protection/required_status_checks so any source can satisfy it. 3. While App A's

CheckRun

for X is IN_PROGRESS, have a different source (e.g. github-actions[bot]) post a SUCCESS commit status under context X. 4. Confirm via the GitHub API that mergeable: MERGEABLE and the required check is satisfied. 5. Open the PR in Graphite — it still shows "Waiting on CI…". Consistent? Yes — reproduces on every PR in this repo that lands in the rollup state described above. Regression? I imagine it's not a regression on Graphite's side — the override workflow that produces this rollup shape is newly added on our end (yesterday). The Graphite "Waiting on CI…" behavior appears to be longstanding; we just hadn't created the conflicting-same-name rollup shape before.

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

Hey John, thanks for the detailed report and repro steps. This was really helpful for tracking down what's happening. You're right that Graphite is blocking on the in-progress CheckRun rather than honoring the newer SUCCESS StatusContext. Here's what's going on: How Graphite evaluates CI readiness today: When Graphite builds the CI rollup for a commit, it collects all CheckRuns and StatusContexts into a flat list and evaluates each one independently. Unlike GitHub, it does not deduplicate entries that share the same name across those two types. So when your rollup contains both: • A CheckRun "Socket Security: Pull Request Alerts" (IN_PROGRESS) • A StatusContext "Socket Security: Pull Request Alerts" (SUCCESS) Graphite sees an outstanding required check and shows "Waiting on CI..." even though GitHub's own resolution logic treats the required check as satisfied. This is a gap in our CI logic. GitHub uses a "most recent wins" approach when a CheckRun and StatusContext share a name, and we don't replicate that behavior today. We'll track this as something to fix. Potential workaround in the meantime: You could restructure which check name is marked as "required" in your branch protection to avoid the name collision. For example: 1. Create a new required check with a distinct name (e.g., "socket-security-status") 2. Have your GitHub Actions workflow post a SUCCESS StatusContext under that new name whenever Socket Security passes or times out 3. Remove "Socket Security: Pull Request Alerts" from your required checks so the app's CheckRun becomes optional/informational That way Graphite would only evaluate the new name (which only ever has a single StatusContext, no conflicting CheckRun), and the Socket Security app's CheckRun would not block the rollup. We still have some work to do on CI checks in general to work around some of the newer github race condition concurrency issues were seeing so ill make sure that this case gets flagged to the team working on that.

Thanks for the quick response! I'll see about implementing that, seems reasonable to me