[yeti-error] review-addresser:list-prs

[frostyardyeti]

Auto-created by Yeti error reporter
Fingerprint: review-addresser:list-prs
Context: frostyard/snosi
Timestamp: 2026-04-01T04:26:14.812Z

Error: gh pr list --repo frostyard/snosi --state open --limit 200 --json number,title,headRefName,baseRefName,labels,author failed: Post "https://api.github.com/graphql": dial tcp 140.82.114.5:443: i/o timeout

    at file:///opt/yeti/dist/github.js:309:28
    at ChildProcess.exithandler (node:child_process:424:5)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1101:16)
    at ChildProcess._handle.onexit (node:internal/child_process:304:5)
    at Process.callbackTrampoline (node:internal/async_hooks:130:17)

[frostyardyeti]

— Automated by Yeti —

Yeti Error Investigation Report

I have all the evidence. Here's the investigation report:

---

Investigation Report: [yeti-error] review-addresser:list-prs

Verified Root Cause

A transient network timeout (dial tcp ... i/o timeout) is not matched by the retry logic in github.ts, so the gh pr list call fails immediately without retries.

The error string:

dial tcp 140.82.114.5:443: i/o timeout

is a Go-level TCP connection timeout from the gh CLI. The retry logic in src/github.ts:366 checks TRANSIENT_RE:

const TRANSIENT_RE = /\b(400|500|502|503|504|ETIMEDOUT|ECONNRESET|ECONNREFUSED|connection reset)\b|Could not resolve to a|TLS handshake timeout|Something went wrong|stream error|unexpected EOF/i;

This regex does not match i/o timeout or dial tcp. I verified this directly:

node -e "TRANSIENT_RE.test('dial tcp 140.82.114.5:443: i/o timeout')"  →  false

The fallback condition !stderr.trim() (line 366) also doesn't help here because stderr contains the error message.

Error Flow

1. review-addresser.run() iterates repos and calls gh.listPRs(repo.fullName) at line 88 of src/jobs/review-addresser.ts
2. listPRs() calls the internal gh() function (line 778)
3. gh() runs execFile("gh", ...) — the gh CLI makes a GraphQL request to GitHub
4. The TCP connection to 140.82.114.5:443 times out (transient network issue)
5. gh exits non-zero with the i/o timeout error on stderr
6. The TRANSIENT_RE check fails to match → no retry attempted
7. The error propagates to the catch block in review-addresser.ts:107-109
8. reportError("review-addresser:list-prs", ...) creates the [yeti-error] issue

Recommended Fix

Add i/o timeout to TRANSIENT_RE in src/github.ts:8. This is clearly a transient network error that should be retried with exponential backoff, just like ETIMEDOUT, ECONNRESET, and TLS handshake timeout.

Updated regex:

const TRANSIENT_RE = /\b(400|500|502|503|504|ETIMEDOUT|ECONNRESET|ECONNREFUSED|connection reset)\b|Could not resolve to a|TLS handshake timeout|Something went wrong|stream error|unexpected EOF|i\/o timeout/i;

This is a one-line change. The i/o timeout pattern is Go's standard network timeout message format, emitted by the gh CLI when TCP connections fail. After this fix, the gh() function will retry up to 3 times (1s, 2s, 4s backoff) before reporting the error — matching the existing behavior for other transient network failures.

[frostyardyeti]

— Automated by Yeti —

Implementation Plan

The issue is clear and the investigation report is thorough. Here's the plan:

Implementation Plan

Summary

Add i/o timeout to TRANSIENT_RE in src/github.ts so that Go-level TCP connection timeouts from the gh CLI trigger the existing retry logic.

Step 1: Update TRANSIENT_RE in src/github.ts

File: src/github.ts, line 8

Append |i\/o timeout to the regex pattern:

// Before:
const TRANSIENT_RE = /\b(400|500|502|503|504|ETIMEDOUT|ECONNRESET|ECONNREFUSED|connection reset)\b|Could not resolve to a|TLS handshake timeout|Something went wrong|stream error|unexpected EOF/i;

// After:
const TRANSIENT_RE = /\b(400|500|502|503|504|ETIMEDOUT|ECONNRESET|ECONNREFUSED|connection reset)\b|Could not resolve to a|TLS handshake timeout|Something went wrong|stream error|unexpected EOF|i\/o timeout/i;

Why: The error dial tcp 140.82.114.5:443: i/o timeout is a transient network failure from Go's TCP dialer (used by the gh CLI). It should be retried with exponential backoff just like ETIMEDOUT, ECONNRESET, and TLS handshake timeout.

Step 2: Add a test case in src/github.test.ts

File: src/github.test.ts

Add a new test following the exact pattern of the existing transient-error tests (e.g., the "retries on transient errors (502)" test at line 113). The test should:

• Use the error message 'Post "https://api.github.com/graphql": dial tcp 140.82.114.5:443: i/o timeout' as stderr
• Verify that the gh() function retries (3 attempts) before succeeding on the final attempt
• Name it: "retries on transient errors (i/o timeout)"

Why: Follows existing test patterns and verifies the regex matches the exact error string from the bug report.

Risks and Edge Cases

• False positives: The string i/o timeout is specific to Go's TCP dialer timeout. It won't match unrelated errors. The /i flag on the regex is already present, so case variations are covered.
• No behavioral risk: This only adds a new match to the retry condition. Existing retry behavior (max 3 attempts, 1s/2s/4s backoff) is unchanged.
• No existing tests break: This is purely additive — a new regex alternative and a new test case.

Testing Approach

Run the existing test suite plus the new test:

npx vitest run src/github.test.ts

[frostyardyeti]

— Automated by Yeti —

Plan Review

Findings:

1. The plan misstates the retry behavior. In src/github.ts:367, MAX_RETRIES = 3 means 3 retries after the initial call, so persistent transient failures can execute gh 4 times total, not “max 3 attempts” as the plan says. That does not block the fix, but the plan’s risk/testing section is describing the current behavior incorrectly.

2. The plan omits the repo docs that currently duplicate the transient-error list. Both yeti/OVERVIEW.md:212 and yeti/modules.md:44 enumerate the retryable gh errors, so they would become stale if i/o timeout is added only in code.

Otherwise the plan is appropriately scoped. Adding i/o timeout to src/github.ts:8 and a positive-match retry test in src/github.test.ts is the right minimal fix.