Observed at commit 2eb7ed4.
pstack/skills/poteto-mode/scripts/watch-pr/github.ts line 5 defines the review-thread query as:
reviewThreads(first: 100) {
nodes { id isResolved comments(first: 10) { nodes { ... } } }
}
It has no pageInfo and no cursor. reviewThreads() at line 571 issues this single query and parseReviewThreads (line 360) reads only reviewThreads.nodes. By contrast, the check-rollup query in the same file (line 9) paginates with pageInfo { hasNextPage endCursor } and a loop (around line 616).
Impact
On a PR with more than 100 review threads, threads after the first 100 are never seen. policy.ts line 66 builds the PR snapshot from this list (line 66), so an unresolved thread beyond the first page is invisible to the readiness decision. Comments beyond the first 10 in a thread are likewise dropped, though that matters less because only thread-level resolution seems to be used.
Minimal reproduction
Run the watcher against a PR with 101+ review threads where only a thread past the first 100 is unresolved; the PR is reported as having no unresolved threads.
Suggested fix
Add pageInfo { hasNextPage endCursor } and an $after cursor to the reviewThreads query and loop until hasNextPage is false, as is already done for contexts. If a hard cap is wanted, report an explicit "truncated" state rather than silently using the first page.
Observed at commit 2eb7ed4.
pstack/skills/poteto-mode/scripts/watch-pr/github.tsline 5 defines the review-thread query as:It has no
pageInfoand no cursor.reviewThreads()at line 571 issues this single query andparseReviewThreads(line 360) reads onlyreviewThreads.nodes. By contrast, the check-rollup query in the same file (line 9) paginates withpageInfo { hasNextPage endCursor }and a loop (around line 616).Impact
On a PR with more than 100 review threads, threads after the first 100 are never seen.
policy.tsline 66 builds the PR snapshot from this list (line 66), so an unresolved thread beyond the first page is invisible to the readiness decision. Comments beyond the first 10 in a thread are likewise dropped, though that matters less because only thread-level resolution seems to be used.Minimal reproduction
Run the watcher against a PR with 101+ review threads where only a thread past the first 100 is unresolved; the PR is reported as having no unresolved threads.
Suggested fix
Add
pageInfo { hasNextPage endCursor }and an$aftercursor to thereviewThreadsquery and loop untilhasNextPageis false, as is already done forcontexts. If a hard cap is wanted, report an explicit "truncated" state rather than silently using the first page.