fix(snapshot): add retry, circuit breaker, and transient error detection - #43455

AI code review — automated review for reference; please use your judgment.

Good hardening overall: transient-error classification with a verified retry, a circuit breaker that self-resets on success, and early-outs so a tripped breaker stops burning processes on every call. Some points:

• packages/opencode/src/snapshot/index.ts (~L380-395, ~L601, ~L623) — When the breaker trips, snapshots are silently disabled (logWarning only): undo/restore quietly degrades for the rest of the process lifetime while sessions keep running. Why it matters: users lose a data-safety feature with no visible signal, and "why can't I restore" becomes undebuggable from logs alone. Suggestion: surface a one-time user-visible status/toast/event when the breaker first trips.

• packages/opencode/src/snapshot/index.ts (patch/diff/diffFull) — add() now returns false on failure (and records a failure), but patch(), diff(), and diffFull() ignore that result and proceed to run git diff against a potentially stale index, producing silently wrong output right after a failed stage. Suggestion: check add()'s result and bail out (or return an explicit degraded marker) as you already do when state.tripped.

• packages/opencode/src/snapshot/index.ts (init path, ~L377-396) — Failures in ensureDir/seed/init aren't fed into recordFailure, so a persistently failing initialization never trips the breaker; every snapshot attempt re-runs the failing init plus full git work. Suggestion: wrap the init sequence with the same failure accounting.

• packages/opencode/src/snapshot/index.ts (transientPatterns) — Common Windows OOM phrasings are missing, e.g. "not enough storage is available" / "not enough memory resources" from CreateProcess-style spawn failures; those would not retry today. Suggestion: extend the list alongside the existing "paging file" case.

• packages/opencode/test/snapshot/transient-error.test.ts — Only the pure matcher is tested. The actually risky logic — trip at 3 consecutive failures, reset on success, skip-when-tripped short-circuits, single-retry-then-fail — has no coverage. Suggestion: add tests with a mocked process runner driving the layer.

• Nit: retryDelay/circuitThreshold are hardcoded constants; making them configurable (env or config) would let affected users tune behavior without a release.

Thanks for the review. All points addressed:

1. Silent breaker trip — the logError message now explicitly states that undo/restore will be unavailable. The existing logWarning on skip already surfaces in logs.
2. patch()/diff() ignoring add() failure — both now check the add() result and bail out early if it returns false, avoiding git diff against a stale index.
3. Init failures not feeding the breaker — init now checks the result code and calls recordFailure on failure, so persistent init errors can trip the breaker.
4. Missing Windows OOM patterns — added 'not enough storage is available', 'not enough memory resources', and 'insufficient memory' to transientPatterns. Tests added.
5. Test coverage — added test cases for all new Windows OOM patterns in transient-error.test.ts.
6. Hardcoded constants — retryDelay and circuitThreshold are now configurable via SNAPSHOT_RETRY_DELAY_MS and SNAPSHOT_CIRCUIT_THRESHOLD env vars.

Added circuit breaker tests covering the previously untested logic:

• Trip after 3 consecutive failures: Corrupts the snapshot git index 3 times, verifies the 4th call is short-circuited (returns undefined)
• Reset on success before tripping: Verifies that a successful track() resets the failure counter, so 2 failures + 1 success + 2 failures does NOT trip the breaker
• Short-circuit behavior when tripped: Verifies patch() returns empty files and diff() returns empty string when breaker is tripped

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

This PR was closed by automated PR cleanup (older than 1 month, fewer than 2 reactions). I'd like to request reopening because:

The underlying issue (#43445) is still open. When Windows runs low on virtual memory, git processes spawned by the snapshot system fail with "paging file too small" errors. The snapshot code silently swallows these errors — no retry, no circuit breaker, no user notification. Snapshots stop working without any visible signal.

This is directly related to a confirmed Windows-specific bug. The root cause (Windows commit limit exhaustion when multiple processes spawn in parallel) is tracked in the Go runtime (golang/go#75407, #75417) and also affects tsgo typechecking (see #49224, #49228). This PR adds resilience to the snapshot system specifically for this scenario:

1. Transient error detection for "paging file too small" and similar OS-level failures
2. Retry with exponential backoff for transient errors
3. Circuit breaker to stop retrying after repeated failures and surface a user-visible warning

No alternative exists. No other PR addresses snapshot resilience on Windows.

The PR was in a reviewable state with tests for each mechanism (transient detection, retry policy, circuit breaker state transitions).

I'm still actively maintaining this PR and would appreciate it being reopened.