conflicted-pr-starts-no-ci-run-push-resolution-first

A Conflicted PR Starts No CI Run — Push the Resolution First

Problem

Your pull request is conflicted. Someone — a coordinator, a landing script, or you — reads its status and sees three fields:

#1234  DRAFT  UNKNOWN (git: CONFLICTED vs origin/main abc1234de)  gates=failure  auto-merge=NOT armed

Two of those three are non-facts. The required check is red because the PR is a draft (in repos where a draft's required context is deliberately red) or because the newest run on that SHA is a stale one that died — either way it is not the blocker. UNKNOWN is not "not conflicted": the provider invalidates mergeability for every open PR each time the base moves and returns UNKNOWN until it recomputes, which is the usual cause on a busy base. The only fact in the line is the parenthesis, which came from git merge-tree.

The expensive half is what is missing: no NEW run is created for as long as the conflict stands. A pull_request workflow runs against the synthetic merge ref, and the provider rebuilds that ref whenever either side moves — so when the two genuinely conflict there is nothing to check out and no run is created. Waiting produces nothing. update-branch cannot fix a conflict. An empty commit does nothing for one either.

And the run list is probably not empty, which is the part that misleads. The head keeps whatever run it earned when it was first pushed, before the base moved and the conflict arose. Measured on the incident below: the conflicted head's run list held exactly one run, created the previous day, whose changes job had SUCCEEDED and whose only red job was the draft's designed-red aggregator. So the queue script's gates=failure was a true reading of a run that had nothing to do with the conflict, and a session checking total_count gets a reassuring non-zero answer. What is diagnostic is the run's AGE, not the count — compare the newest run's created_at against the base branch's last merge.

Context / Trigger Conditions