test-action-on-github.sh left one open PR behind on a target repo when it reset the harness. Seen 2026-09-21 on the v0.29.2 gate (tally on #318).
What happened
The v0.29.1 gate ran at 11:30 UTC and opened 28 translation PRs on QuantEcon/test-translation-sync.ml. The v0.29.2 gate ran at 13:02 UTC; its reset is meant to close every open PR on all four repos before force-pushing main and opening new fixture PRs. After it, the .ml lane had 29 open PRs: this gate's 28, plus test-translation-sync.ml#192 — scenario 01 from the earlier gate (branch translation-sync-2026-09-21T11-30-57-pr-891, verdict stamped 0.29.1). The zh-cn and fa lanes reset cleanly to 28.
Between the two gates the .ml lane had 31 open PRs rather than 28 (one from a re-run of a failed job, two from local-bundle validation runs), so the close-all step had more than the usual number to get through on that repo. #192 was the lowest-numbered of them.
Why it matters
The gate is read from per-lane PR counts and per-PR verdict stamps. A survivor makes the lane read 29 PRs / 28 stamped at the wanted version, which looks like a missing verdict until someone lists the PRs. It was closed by hand this time. A stale PR that happened to carry the wanted version would be worse: it could mask a missing delivery.
Cause
gh pr list defaults to 30 results, and neither reset loop passes --limit: tool-test-action-on-github/test-action-on-github.sh lines 622 and 633 (source repo) and line 655 (each target repo) all read gh pr list --repo … --state open --json number. With 31 open PRs on the .ml lane, the list returned the newest 30 and the oldest — #192 — was never seen. A normal gate leaves exactly 28, under the default, which is why this has not shown before; any diagnosis work between two gates (a re-run, local-bundle validation) can push a lane past 30.
Suggested change
- Pass an explicit
--limit well above the scenario count (e.g. --limit 200) on all three gh pr list calls, or loop until the list comes back empty.
- Add a post-reset assertion: after closing, each repo should report zero open PRs before any fixture PR is created, and the script should stop if not. That makes this class loud whatever its cause — including a
gh pr close that fails transiently, which the loop at lines 639 and 664 does not currently check.
test-action-on-github.shleft one open PR behind on a target repo when it reset the harness. Seen 2026-09-21 on the v0.29.2 gate (tally on #318).What happened
The v0.29.1 gate ran at 11:30 UTC and opened 28 translation PRs on
QuantEcon/test-translation-sync.ml. The v0.29.2 gate ran at 13:02 UTC; its reset is meant to close every open PR on all four repos before force-pushingmainand opening new fixture PRs. After it, the.mllane had 29 open PRs: this gate's 28, plus test-translation-sync.ml#192 — scenario 01 from the earlier gate (branchtranslation-sync-2026-09-21T11-30-57-pr-891, verdict stamped0.29.1). The zh-cn and fa lanes reset cleanly to 28.Between the two gates the
.mllane had 31 open PRs rather than 28 (one from a re-run of a failed job, two from local-bundle validation runs), so the close-all step had more than the usual number to get through on that repo. #192 was the lowest-numbered of them.Why it matters
The gate is read from per-lane PR counts and per-PR verdict stamps. A survivor makes the lane read 29 PRs / 28 stamped at the wanted version, which looks like a missing verdict until someone lists the PRs. It was closed by hand this time. A stale PR that happened to carry the wanted version would be worse: it could mask a missing delivery.
Cause
gh pr listdefaults to 30 results, and neither reset loop passes--limit:tool-test-action-on-github/test-action-on-github.shlines 622 and 633 (source repo) and line 655 (each target repo) all readgh pr list --repo … --state open --json number. With 31 open PRs on the.mllane, the list returned the newest 30 and the oldest — #192 — was never seen. A normal gate leaves exactly 28, under the default, which is why this has not shown before; any diagnosis work between two gates (a re-run, local-bundle validation) can push a lane past 30.Suggested change
--limitwell above the scenario count (e.g.--limit 200) on all threegh pr listcalls, or loop until the list comes back empty.gh pr closethat fails transiently, which the loop at lines 639 and 664 does not currently check.