[ErickMachado]

Why

Keep watch-pr from reporting ready while Actions workflows are starting, without letting an obsolete failed or cancelled execution block a successful replacement.

Summary

read registered checks and head-scoped Actions runs
  require complete, bounded run pagination
  select the newest execution per automatic workflow context
  preserve independent contexts and current registered failures
  wait for queued or running work
  reread the PR head and state before reporting ready

Execution identity uses workflow ID, event, head repository, branch and PR associations. Run number orders replacements; attempt number orders retries. The Code Review Gate owner-approval exception remains intact.

Scope

Manual dispatches, unknown trigger contexts and multiple PR associations remain conservative. GitHub's PR associations do not identify the triggering PR. This does not provide an atomic GitHub snapshot or change the installed Pi bundle.

Evidence

• Before the startup fix, passing partial checks plus a queued workflow returned READY (0). The CLI now waits and reaches the fixture deadline with TIMEOUT (5).
• The correction regression first reproduced BLOCKER (4) for cancelled or failed run 100 plus successful replacement 101 with passing current checks. Both now return READY (0). The CLI matrix also preserves current failures, queued replacements, independent contexts and retryable pagination errors.
• Source tests pass 108/108. Strict typecheck, plugin validation and generated-tree checks pass. A separate CLI proof passes all 28 cases, including the original eight lifecycle cases. The root Node suite has 266 passes, one unchanged base-reproduced statechart symlink failure and 67 missing-TLC skips.

Merge Danger

Door: Two-way. Revert the watcher changes to restore prior behavior.

Blast Radius: Watch-pr readiness. Incomplete, unstable or capped Actions observations now become retryable query errors rather than false readiness. Filtered totals of at least 1,000 fail closed because GitHub caps those searches.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Superseded runs block readiness

Medium Severity · Logic Bug

Latest-attempt selection is keyed by run id, so every head-scoped workflow run joins classification. A cancelled earlier run of the same workflow still counts as failed when a newer run is queued or green, so the watcher reports a CI blocker instead of waiting.

Additional Locations (2)

• pstack/skills/poteto-mode/scripts/watch-pr/policy.ts#L81-L87
• pstack/skills/poteto-mode/scripts/watch-pr/github.ts#L504-L514

 

^{Reviewed by Cursor Bugbot for commit 43bc757. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.}

^{Reviewed by Cursor Bugbot for commit e7804d2. Configure here.}

[cursor]

Nullable head repo fails snapshot

Medium Severity · Logic Bug

parseWorkflowRunPage now requires head_repository.id on every workflow run. GitHub can return head_repository as null when the head repo is gone, so one valid row fails the whole Actions read and the watcher surfaces a status-query blocker instead of classifying that run. head_branch already allows null on the same object.

 

^{Reviewed by Cursor Bugbot for commit e7804d2. Configure here.}

[deanrie]

Hey @ErickMachado, two notes from reading this against the other open watch-pr PRs.

1. It conflicts with fix(pstack): watch-pr --status-only reports a head with no checks instead of retrying #769 (--status-only on a head with no checks, for pstack: watch-pr --status-only retries for minutes on a repo with no checks #750) on the same hunk of readSnapshot in policy.ts: fix(pstack): watch-pr --status-only reports a head with no checks instead of retrying #769 wraps the resolveChecks call in a try/catch for ChecksUnavailable, this PR adds the workflowRuns read right after that call. git merge-tree is clean against main, fix(watch-pr): wait while GitHub is still computing mergeability #848, fix(watch-pr): wait while the head branch is behind its base #856 and feat(pstack): install pstack in Google Antigravity from a generated tree #953; only fix(pstack): watch-pr --status-only reports a head with no checks instead of retrying #769 collides, and the resolution is mechanical (keep the try/catch, then the workflow read). Whichever lands second needs that rebase.

2. Ordering: resolveChecks still throws ChecksUnavailable when both gh pr checks and the GraphQL rollup come back empty, and that happens before workflowRuns is called. So for a head where no check has registered yet but a workflow is already queued, the loop still goes through the retryable query-error path rather than ci-pending; the workflow read is only reached once at least one check exists. The cli.test.ts fixture registers two passing checks, which is why it does not show there. Nothing reports READY in that window, so it is not a correctness problem, but if the intent is to surface the queued workflow in that window too, the workflow read has to come before the empty-check throw.

[deanrie]

Adding to the note above: the three PRs that each close one READY-too-early window merge cleanly together as well, not only pairwise with main: #848 (mergeable: UNKNOWN) + #1124 + #856 (BEHIND) in a three-way git merge-tree on main 23ab063 produce no conflict, the harness tree check passes on the result, and bun test in poteto-mode/scripts is 108 pass, 0 fail with workflow-runs.test.ts included. @MaxHarris-1's #1053 is the user-side report of the same behaviour, in case you want to reference it.