reviewer: GitHub CLI/API transient failures in discover/snapshot are persisted as non-retryable

[mrcfps]

Summary

Some reviewer failures caused by transient GitHub API/CLI errors are persisted as non_retryable instead of being retried.

Evidence

Recent failed reviewer loops:

loop	step	error kind	error
211	discover	non_retryable	Post "https://api.github.com/graphql": unexpected EOF
219	discover	non_retryable	Post "https://api.github.com/graphql": net/http: TLS handshake timeout
357	snapshot	non_retryable	HTTP 504: We couldn't respond to your request in time
241	discover	non_retryable	GraphQL: Could not resolve to a PullRequest with the number of 345

The first three are clear transient infrastructure failures and should be retried. The fourth is a stale/nonexistent PR case and should be skipped/cancelled, not failed as a reviewer bug.

Root cause

The codebase has a GitHub transient classifier:

• internal/infra/github/errors.go:23-44 — IsTransientError
• internal/infra/github/errors.go:62-90 — detects tls handshake timeout, unexpected eof, http 504, etc.
• internal/reviewer/runner.go:3226-3228 — maps githubinfra.IsTransientError(err) to FailureRetryableTransient

But production DB records show these errors are still ending as non_retryable. This suggests at least one of:

1. the gateway/adapter path is wrapping GitHub CLI errors into plain strings that no longer satisfy the transient classifier,
2. discover-step failures are not going through the same transient retry/classification path as snapshot/review,
3. stale PR-not-found errors are not distinguished from infrastructure failures.

Also, reviewerStepSupportsTransientExternalRetry only includes:

stepSnapshot, stepThreadResolution, stepReview

and does not include stepDiscover, even though discover performs GitHub GraphQL calls.

Expected behavior

• GitHub network/service failures should be retried with bounded backoff and recorded as retryable_transient if the retry budget is exhausted.
• Could not resolve to a PullRequest should become skipped/cancelled if the PR no longer exists, not a failed reviewer run.
• Discover should participate in the same transient external retry policy as snapshot/review.

Proposed fix

• Include stepDiscover in reviewerStepSupportsTransientExternalRetry.
• Add tests covering real gateway/CLI error values for discover and snapshot paths, not just synthetic TransientError wrappers.
• Classify PR-not-found / deleted PR as a terminal skip/cancel reason.
• Ensure queue/loop error summaries preserve the original GitHub error while using the correct retry kind.

[mrcfps]

Additional recent evidence from the last-hour reviewer failures:

Recent failed reviewer loops:

loop	PR	run duration	queue error kind	agent status	parse status
471	nexu-io/open-design#642	220s	non_retryable	completed	missing
467	nexu-io/open-design#635	57s	non_retryable	completed	missing
468	nexu-io/open-design#631	93s	non_retryable	completed	missing
453	nexu-io/open-design#617	84s	non_retryable	completed	missing
469	nexu-io/open-design#626	81s	non_retryable	completed	missing

The actual failure in all five is GitHub connectivity inside the agent-run gh commands, e.g.:

gh pr view https://github.com/nexu-io/open-design/pull/642 -R nexu-io/open-design --json ...
exited 1:
error connecting to api.github.com
check your internet connection or https://githubstatus.com

The agent then stops safely and emits a JSON-looking diagnostic, for example:

{"type":"network","message":"gh failed while fetching live PR metadata from api.github.com, so I stopped before reviewing or publishing as required.","observed_pr_metadata":null}

But because it does not print the exact __LOOPER_RESULT__={...} completion marker, Looper records:

Reviewer agent did not report a valid completion marker after publishing review
last_error_kind = non_retryable

So this issue is not limited to runner-owned discover/snapshot GitHub calls. The same transient GitHub classification needs to apply to agent-owned gh failures that appear in AgentResult.Summary, Stdout, or Stderr when Status=completed and ParseStatus=missing.

Suggested additional fix:

Before returning the generic non-retryable missing-marker error in runReviewStep, inspect agent output for GitHub transient messages:

• error connecting to api.github.com
• check your internet connection or https://githubstatus.com
• existing githubinfra.IsTransientError fragments such as TLS handshake timeout, unexpected EOF, HTTP 504, etc.

If detected, return FailureRetryableTransient so the existing retry/backoff/queue path can handle it instead of failing the loop.

[mrcfps]

Looper finished work on this issue.

Pull request: #228

_{Generated by Looper 0.6.0 · runner=worker · agent=codex}