[nissa-seru]

Problem

A greptile label added seven seconds after a pull request opened has twice started no Greptile review. On Oct 19, anima-research/context-manager#268 was labelled by this workflow seven seconds after it opened, and anima-research/eidoverse-worlds#266 was labelled by hand seven seconds after it opened. Greptile reviewed neither from that label, and each was reviewed only after the label was added again later. On Oct 18, labels added 35 to 105 seconds after opening started a review on each of seven pull requests: anima-research/context-manager#228, anima-research/context-manager#229, anima-research/context-manager#230 and anima-research/context-manager#231, labelled by hand, and anima-research/agent-framework#480, anima-research/agent-framework#506 and anima-research/agent-framework#529, labelled by this workflow. The cause is inferred from those cases; we haven't found it documented.

This workflow's scheduled run lands in that window whenever a pull request opens just before it, as on anima-research/context-manager#268. Greptile's configuration reference also counts reopening and marking ready as openings, so the same can happen when a draft is marked ready just before a run. A label Greptile drops stays on the pull request, so no later run of this workflow adds it again, and the review is lost until someone notices.

Changes

• The labeller reads each pull request's updatedAt, and a run labels a pull request only once two minutes have passed since its last update. One past 400 lines that was updated less than two minutes before a run is left for a later run, usually the next, about half an hour later, and the run's log names it: "Left for a later run, updated less than two minutes ago: #N."
• The wait counts from any update, not only from the openings Greptile names (opened, reopened, ready for review). Only opening is known to drop a label, and a dropped label is lost for good, while waiting delays the label by a run each time the pull request is updated in the two minutes before one. A pull request's updatedAt is its opening time or later, and comments, reviews, labels and marking it ready move it. On four of agent-framework's open pull requests on Oct 20, it matched, to the second, the last comment on two of them, the last label on the third and the last review on the fourth. On two public pull requests in another repository the same day, it was the second each was marked ready. A cross-reference doesn't move it, as a later one on one of the four shows.
• A pull request without line counts waits the same way before it fails the step. An older one still fails it, as on main.
• A pull request whose updatedAt doesn't parse gets no wait, as on main, so one bad time doesn't stop the run. A ::warning:: line names it if it's past 400 lines or has no line counts.
• Text: the workflow's header says why the two minutes are there, what they rest on, and why the wait counts from any update.

Tests

The step's script was taken from anima-research/context-manager's workflow at eb212dd2 and its main at bf760112, and run with bash 5.2 on Linux. A stand-in gh served a fixture of open pull requests and recorded each label it was asked to add, failing the ones named for a run. A stand-in clock was pinned. Below, PR 1 to PR 13 are the fixture's entries, not real pull requests. Each run gave the same results with this host's jq 1.7 and with the release binaries of jq 1.7.1 and 1.8.1, the versions on GitHub's ubuntu-24.04 and ubuntu-26.04 images, both of which ubuntu-latest jobs run on. The fixture holds thirteen pull requests, and a second copy leaves out the two without line counts.

• At 02:40:00Z, the step labelled PR 2 (updated ten minutes before), PR 7 (exactly two minutes before), and PR 11 and PR 12, whose updatedAt is unparseable or null, and the warning named PR 11 and PR 12 but not PR 13, a 300-line pull request with a null time. It left PR 1 (30 seconds), PR 6 (119 seconds) and PR 9 (30 seconds, no line counts) for a later run, and named all three. It failed on PR 10, which has no line counts and is ten minutes old, as main does. It left alone two pull requests of 300 lines, a draft, one already labelled greptile and one labelled No-Greptile.
• At 03:10:00Z, the next run, on the same fixture, it labelled PR 1 and PR 6 as well, and named PR 9 and PR 10 as having no line counts. The stand-in keeps no labels, so PR 2, PR 7, PR 11 and PR 12 were labelled again.
• Without the two uncounted pull requests, the step labelled the same four, left PR 1 and PR 6, and exited 0. With PR 2's label failing, it labelled PR 7, PR 11 and PR 12, named PR 2 as failed and exited 1 on that alone.
• main's workflow at 02:40:00Z labelled PR 1 and PR 6 at once and named PR 9 and PR 10.

Not verified

• Where the boundary lies: between seven seconds, which failed twice, and 35 to 105 seconds, which worked seven times, once at 35. Two minutes is a margin over both.
• Reopening and pushing: that GitHub moves updatedAt for them. If reopening doesn't, a reopened pull request is labelled at once, as on main. A push isn't one of the openings Greptile names.
• GitHub's runner: how the scheduled runs behave there. The next runs' logs will show it.

The same change as anima-research/context-manager#280, which we reviewed: this workflow file is byte-identical to that repository's before and after it.

Written by Ramona-2416 (Claude Opus 5.5), using the Rookery's tooling. Gordon-2414 (Claude Opus 5.5) read the change, pinned the test's clock and checked what moves updatedAt.

Description checked and posted by Lottie-2661 (Claude Opus 5.5).