You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pstack: watch-pr --status-only retries for minutes on a repo with no checks #750
On a PR in a repository that reports no checks, watch-pr --status-only never prints a status. It prints
RETRY: GitHub status query failed; retrying in 60s
detail=could not read PR checks: fast path exit=1; GraphQL rollup was empty; no checks reported on the '<branch>' branch
and retries after 60, 120 and 240 s before giving up. Babysit's check mode calls --status-only and expects one status line, so the check stalls for minutes.
Repro. Open a PR in any repository with no CI or check apps, then run:
Cause. When both gh pr checks and the GraphQL rollup are empty, resolveChecks throws a retryable ChecksUnavailable (github.ts L630). readSnapshot has no state for a PR without checks (policy.ts L71). runSimple sends --status-only through pollUntilTerminal with the full --max-query-errors budget (policy.ts L513), so the error is retried with backoff.
A fix. A downstream fork fixed it in two small PRs, with tests:
Polling mode is deliberately unchanged. A head that was just pushed has no checks yet either, so treating "no checks" as ready while polling would report READY too early.
Seen on pstack 0.15.25. policy.ts and github.ts are unchanged on main at 190d287.
Hey, the two downstream fixes you linked were the right shape, so #769 brings them into this tree as one change: readSnapshot takes noChecks: "report" | "retry", --status-only is the only caller that passes "report" and gets a ci-none row (merge assessment still read, so a GitHub-side refusal is kept), and that mode also runs with a one-error query budget so it never sleeps through the backoff schedule. Polling is untouched, for the reason you gave: a head that was just pushed looks identical and must not be called ready. --pretty shows no checks reported, and the help line for --status-only now says it reads GitHub once. Tests cover report/retry on readSnapshot, the JSON and --pretty status output, the first-error exit, and polling still emitting RETRY; 74/74, tsc clean, no overlap with #746. If you still have the no-checks repository handy, running the branch's watch-pr --pr <n> --status-only --pretty against it is the one check I could not do from here.
Activity
deanrie commentedon Oct 22, 2026
Hey, the two downstream fixes you linked were the right shape, so #769 brings them into this tree as one change:
readSnapshottakesnoChecks: "report" | "retry",--status-onlyis the only caller that passes"report"and gets aci-nonerow (merge assessment still read, so a GitHub-side refusal is kept), and that mode also runs with a one-error query budget so it never sleeps through the backoff schedule. Polling is untouched, for the reason you gave: a head that was just pushed looks identical and must not be called ready.--prettyshowsno checks reported, and the help line for--status-onlynow says it reads GitHub once. Tests cover report/retry onreadSnapshot, the JSON and--prettystatus output, the first-error exit, and polling still emittingRETRY; 74/74, tsc clean, no overlap with #746. If you still have the no-checks repository handy, running the branch'swatch-pr --pr <n> --status-only --prettyagainst it is the one check I could not do from here.