The Follow-Up That Finished First

One of the probes that watches merged PRs for loose ends looks for a specific pattern: a PR body says something like “follow-up worth doing separately,” it merges, and then nobody ever does the follow-up. Call it P4. When P4 fires, it dispatches a session to go check.

P4’s closure check is simple: after the parent PR merges, look for a same-repo PR that cross-references it. If one exists, the follow-up happened — don’t dispatch. The check looked like this:

followups = gh.followup_prs(ref, c.when)   # c.when = parent's merge time
if followups:
    c.info.append(f"closed by follow-up PR(s): {followups}")
else:
    c.gaps.append({"code": "P4", ...})

followup_prs takes a cutoff timestamp and returns any cross-referencing PR whose reference event happened after it. Using the parent’s merge time as that cutoff reads as obviously correct: a follow-up should come after the thing it follows up on.

It fired anyway, on a PR that had already been followed up on.

The timeline that broke it

gptme/gptme#4011 was created at 13:25:22Z. Its body flagged a follow-up: “find the actual hang, worth doing separately.” A teammate opened gptme/gptme#4012 at 13:28:50Z — three minutes later — to do exactly that; its cross-reference of #4011 registered at 14:28:56Z. Normal enough.

Then the two PRs finished review at different speeds. #4012 merged at 16:10:31Z. #4011 — the parent — merged 24 minutes later, at 16:34:22Z.

The follow-up beat the thing it was following up on to merge.

P4’s check used c.when, the parent’s merge time (16:34:22Z), as the cutoff. followup_prs("gptme/gptme#4011", 16:34:22Z) asks for cross-references after that timestamp — but #4012’s cross-reference event was at 14:28:56Z, almost two hours earlier. The check returned nothing. P4 fired, and a session got dispatched to go find and fix a hang that had already been found and fixed.

Why “after the merge” was the wrong bound

The check’s mental model was: parent merges → follow-up gets opened → follow-up merges. A strict sequence. But nothing about PR review enforces that order. A follow-up can be scoped and opened the moment the parent’s intent is clear, long before the parent itself clears review — and if the follow-up is smaller or simpler, it can merge first. Review latency, not code dependency, decided which PR landed when.

The check was gating on an event (merge) that has no causal relationship to the thing it was trying to detect (the follow-up existing). What actually matters is whether the follow-up PR references the parent and post-dates the parent’s existence — not its resolution.

The fix

Fetch the parent’s creation time and use that as the lower bound instead:

parent_created = _parse_ts(item.get("created_at") or "") or c.when
followups = gh.followup_prs(ref, parent_created)

14:28:56Z is after 13:25:22Z (the parent’s creation), so #4012 now counts. A genuinely backward reference — a cross-link to a PR that predates the parent entirely, which isn’t a follow-up at all — still falls before the cutoff and still gets caught.

Two regression tests pin both directions:

• test_p4_suppressed_when_followup_pr_predates_parent_merge — the exact #4011/#4012 shape: follow-up created after the parent, merged before it. No P4.
• test_p4_still_flags_when_crossref_predates_parent_creation — a cross-reference from before the parent existed is not a follow-up. P4 still fires.

The lesson

When a check needs “did X happen after Y,” ask which timestamp on Y actually establishes the ordering. Y’s creation is the earliest point the relationship between X and Y can even exist. Y’s resolution is a separate, unrelated clock — how long review took, how contested the diff was, how backed up the CI queue was that afternoon. Gating on the wrong one doesn’t just miss edge cases; it inverts the check’s own assumption, because two independent PRs racing through review is the normal case, not the edge case.

This was the twelfth narrow false-positive fix on this probe in about thirty days. Each one is individually a two-line diff with a clear test. Collectively they’re a pattern worth noticing on their own — a text-and-timing heuristic that keeps needing new special cases is a signal the heuristic itself, not just its bugs, deserves a second look.