Summary
When Gittensory's own review pass takes materially longer than the underlying CI, a PR can sit in an "unreviewed but CI-green" state for many minutes. If another PR touching the same file(s) merges into the base branch during that window, the open PR becomes conflicting through no action of its own author — and is then auto-closed for "conflicts with the base branch" once Gittensory finally gets to it. The close decision itself is technically correct (the PR really is unmergeable by the time it's evaluated); the problem is that Gittensory's own latency is what created the collision window in the first place.
Area
Signal logic / GitHub App (review scheduling, regate sweep timing)
Expected behavior
For a PR whose real CI (tests/lint/build) completes quickly, Gittensory's own review pass should complete on a comparable timescale, minimizing the window in which a same-file collision with the base branch can occur before the PR is evaluated.
Actual behavior
Observed a case where the underlying CI suite finished in ~4 minutes, but Gittensory's own review comment/verdict didn't post until ~29 minutes after the PR opened. An unrelated PR touching the same file merged into the base branch about 10 minutes into that window. By the time Gittensory reviewed, the PR was CONFLICTING and was closed with "conflicts with the base branch (resolve and open a fresh PR)."
Reproduction (real-world case, JSONbored/metagraphed)
JSONbored/metagraphed#3851 opened 2026-07-06T11:28:56Z. All real CI checks (test/checks/ui/codecov/superagent) completed by 2026-07-06T11:32:26Z.JSONbored/metagraphed#3818 (an unrelated feature, touching the same shared file apps/ui/src/routes/accounts.$ss58.tsx) merged into main at 2026-07-06T11:38:09Z.- Gittensory's own review comment on
#3851 wasn't posted until 2026-07-06T11:57:34Z (~29 minutes after open), and the PR was closed at 2026-07-06T11:57:57Z for the resulting conflict.
Validation
Compare check-run started_at/completed_at timestamps (real CI) against the Gittensory review comment's createdAt on the same PR — the ~25-minute gap between "CI green" and "Gittensory acts" is the exposure window. This is a genuinely hard one to close outright (GitHub's merge semantics plus concurrent contribution volume mean there will always be some collision risk), so this issue is meant to track/bound the problem rather than demand it be eliminated entirely.
Suggested fix / discussion
- Where feasible, re-check
mergeable/mergeable_state immediately before acting on a review verdict (close/merge), rather than trusting whatever state was current when the review pass started — so a very recent conflict is caught freshly rather than compounding an already-stale evaluation.
- Continue the review-latency work already in flight (duplicate-cluster winner-by-creation-time, issue-triggered re-gating, regate-sweep reliability) — tightening the review-start-to-verdict latency directly shrinks this race window.
- Open question: for a PR that becomes conflicting after a review pass was already in progress (i.e. not stale from open), it may be worth a distinct, softer message than the standard "resolve and open a fresh PR" close, since the timing wasn't the contributor's fault. Flagging for discussion, not prescribing.
Impact
Harder to eliminate outright than the linked-issue syntax bug, but worth tracking explicitly — it's a real, reproducible source of "unfair-feeling" closes at current contribution volumes, and shrinking Gittensory's own review latency is the direct lever that reduces it.
Summary
When Gittensory's own review pass takes materially longer than the underlying CI, a PR can sit in an "unreviewed but CI-green" state for many minutes. If another PR touching the same file(s) merges into the base branch during that window, the open PR becomes conflicting through no action of its own author — and is then auto-closed for "conflicts with the base branch" once Gittensory finally gets to it. The close decision itself is technically correct (the PR really is unmergeable by the time it's evaluated); the problem is that Gittensory's own latency is what created the collision window in the first place.
Area
Signal logic / GitHub App (review scheduling, regate sweep timing)
Expected behavior
For a PR whose real CI (tests/lint/build) completes quickly, Gittensory's own review pass should complete on a comparable timescale, minimizing the window in which a same-file collision with the base branch can occur before the PR is evaluated.
Actual behavior
Observed a case where the underlying CI suite finished in ~4 minutes, but Gittensory's own review comment/verdict didn't post until ~29 minutes after the PR opened. An unrelated PR touching the same file merged into the base branch about 10 minutes into that window. By the time Gittensory reviewed, the PR was
CONFLICTINGand was closed with "conflicts with the base branch (resolve and open a fresh PR)."Reproduction (real-world case, JSONbored/metagraphed)
JSONbored/metagraphed#3851opened2026-07-06T11:28:56Z. All real CI checks (test/checks/ui/codecov/superagent) completed by2026-07-06T11:32:26Z.JSONbored/metagraphed#3818(an unrelated feature, touching the same shared fileapps/ui/src/routes/accounts.$ss58.tsx) merged intomainat2026-07-06T11:38:09Z.#3851wasn't posted until2026-07-06T11:57:34Z(~29 minutes after open), and the PR was closed at2026-07-06T11:57:57Zfor the resulting conflict.Validation
Compare check-run
started_at/completed_attimestamps (real CI) against the Gittensory review comment'screatedAton the same PR — the ~25-minute gap between "CI green" and "Gittensory acts" is the exposure window. This is a genuinely hard one to close outright (GitHub's merge semantics plus concurrent contribution volume mean there will always be some collision risk), so this issue is meant to track/bound the problem rather than demand it be eliminated entirely.Suggested fix / discussion
mergeable/mergeable_stateimmediately before acting on a review verdict (close/merge), rather than trusting whatever state was current when the review pass started — so a very recent conflict is caught freshly rather than compounding an already-stale evaluation.Impact
Harder to eliminate outright than the linked-issue syntax bug, but worth tracking explicitly — it's a real, reproducible source of "unfair-feeling" closes at current contribution volumes, and shrinking Gittensory's own review latency is the direct lever that reduces it.