Bug: cancelled CI runs count as "Failing required" in automation triggers, so stack merges self-trigger our "Notify author when CI fails" automation. Cancelled GitHub Actions runs count as failing CI in automation trigger evaluation. Merging the bottom PR of a stack makes Graphite restack and force-push the PRs above it, and under a standard

concurrency: cancel-in-progress

config that force-push cancels their in-flight runs. So on every stack merge, the PRs above get a false "CI fails" notification. Graphite's docs (graphite.com/docs/stacking-and-ci) describe restacks generating cancelled runs as normal stacking behavior, which means the trigger fires on a condition stacking itself creates. It gets worse because automations "match once per PR and won't re-trigger." A false fire on a cancellation spends the PR's only notification. If that PR later has a real CI failure, the author never hears about it. Repro, entirely on the Graphite happy path with no manual merging: take a repo with cancel-in-progress workflows, build a stack with the bottom PR approved and CI green, enable the automation, then enable "merge when ready" on the top PR so it cascades down the stack. Graphite merges the bottom PR and force-pushes the PRs above it. GitHub cancels their superseded runs, and the automation matches them even though no check failed. Auto-merge walks up the stack, so this repeats at every merge point. We saw it twice in one afternoon (CondorSoftware/condor, Jul 15, 4-PR stack): Graphite merged #9586 at 1:55 PM and the automation matched its descendant #9587 within the same minute. #9587 had zero failed checks all day. When #9589 merged at 2:46 PM, the automation immediately matched #9590, which also had zero failed checks. Screenshots attached. I cross-referenced the GitHub API to confirm the chain (times UTC): • #9586 merged at 195526Z. The PR timeline shows force-pushes of #9587's branch at 195602Z and 195636Z. The Actions API shows 14 runs on that branch cancelled between 195608Z and 195647Z, and the Slack ping landed the same minute. • The second firing has the same shape: merge at 204632Z, force-pushes at 204658Z and 204733Z, 14 runs cancelled from 204704Z to 204742Z, ping at about 20:47. • Across the whole day the two branches had 50 and 73 successful runs, 19 and 21 cancelled, and zero runs with

conclusion: failure

. There was never a failed run to report. What I'd expect: a cancelled run should not satisfy "Failing required". I checked the trigger's full option list (screenshot attached in thread): "CI status equals" offers Passing all, Passing required, Failing required, Failing non-required, and Completed all. Cancelled has no place in that taxonomy, so the evaluator is presumably folding it into Failing. Treating cancelled as its own status would fix this with no UI change needed on our side, and a separate "Cancelled" trigger option could serve anyone who actually wants to alert on cancellations. At minimum, a cancellation caused by a Graphite-initiated restack should never count as failing, since Graphite knows it caused it. As it stands, none of the five options distinguishes a failed run from a cancelled one, so our only options are living with the noise or dropping the automation. Please let me know if this is a known issue and whether there are any workarounds we've missed.

Thank you for your extremely detailed report. I was able to duplicate this and have written a report for the team. No ETA to relay on a fix today but your leg work helped clearly identify our gap here. Once we have a resolution I will double back and alert you. Thanks!