fix(opencode): cap session retries with jitter

[rekram1-node]

Issue for this PR

Closes #37076

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Caps the high-level session retry policy at five retries so persistent retryable provider failures terminate instead of running indefinitely. Adds up to 25% jitter to locally computed exponential delays while continuing to honor explicit provider retry delays unchanged.

How did you verify your code works?

• bun test test/session/retry.test.ts from packages/opencode: 54 passed
• bun typecheck from packages/opencode: passed
• Added coverage for jitter bounds and retry schedule exhaustion

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[chenxuan520]

This is a behavior regression for users who intentionally wait through provider capacity/rate-limit shortages. Before this PR, retryable provider failures with explicit Retry-After / retry-after-ms could keep retrying until the provider recovered. After this PR, all high-level session retries are forced to stop after 5 attempts, even when the provider is explicitly telling the client to wait and retry.

The hard cap is too blunt, and there is no config/opt-out in opencode.json to restore the previous behavior. That makes this a user-visible breaking change for long-running sessions and enterprise/custom providers where transient capacity shortages can last longer than five seconds or five retry windows.

Please either make the retry limit configurable, including an unlimited option, or scope the cap only to locally computed exponential retries without provider retry headers. Explicit provider retry headers should not be treated the same as blind infinite retry loops.

[chenxuan520]

Concrete fix proposal:

1. Do not apply the hard 5-attempt cap to provider-directed retries. If the API error has retry-after or retry-after-ms, the provider is explicitly telling the client to wait and retry. That should not be treated the same as a blind infinite exponential loop.

2. Add a user-visible config knob instead of hard-coding this behavior. For example:

{
  "retry": {
    "max_retries": 5,
    "provider_retry_after_max_retries": false
  }
}

or a simpler first pass:

{
  "retry": { "max_retries": 5 } // number | false, where false means unlimited
}

3. Thread that config into SessionRetry.policy(...) from packages/opencode/src/session/processor.ts instead of relying on RETRY_MAX_RETRIES as an unconfigurable constant.

4. Minimal behavior change if you want to keep the current default:

const headers = SessionV1.APIError.isInstance(error) ? error.data.responseHeaders : undefined
const hasProviderRetryAfter = !!headers?.["retry-after"] || !!headers?.["retry-after-ms"]
if (!hasProviderRetryAfter && meta.attempt > maxRetries) return Cause.done(meta.attempt)

5. Tests that should be added:

• retryable 503/429 without retry headers stops at the configured default
• APIError with retry-after-ms continues past the default cap
• APIError with retry-after continues past the default cap
• retry.max_retries = false preserves the previous unlimited behavior
• retry.max_retries = N caps at N for non-provider-directed retries

The important distinction is: local exponential retries need a safety cap; provider-directed retry headers need either unlimited behavior or a separate user-configurable cap. Right now this PR collapses both cases into one hard-coded limit, which is the regression.

[chenxuan520]

@rekram1-node please take a look at the regression described above. The problematic part is not just the default cap; it is that the cap is hard-coded and has no user-visible config or provider retry-header exception.

For provider responses that include retry-after or retry-after-ms, the provider is explicitly instructing the client to wait and retry. Those should either remain unlimited like before, or have a separate configurable cap. Applying the same hard 5-attempt limit to both blind exponential retries and provider-directed retries breaks long-running/internal-provider workflows.

Can you make this configurable or exempt provider-directed retry headers from the hard cap?