fix(opencode): stop retrying when the provider asks to wait for hours

[ApexMene]

Issue for this PR

Closes #39790

Type of change

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

What does this PR do?

SessionRetry.delay() returns whatever the provider puts in retry-after, capped only by RETRY_MAX_DELAY (~24.8 days). policy() then schedules the next attempt that far out, so an exhausted quota window parks the session on one pending attempt that can be a full day away. Nothing is logged after the first stream error, no session.error is published, and the session never reaches idle.

zen is one concrete source: getRetryAfterDay() in packages/console/app/src/routes/zen/util/ipRateLimiter.ts sets retry-after to the seconds left until the next daily reset, so an exhausted free tier can answer with up to 86400.

The change stops the schedule when the requested wait is longer than RETRY_MAX_WAIT (5 minutes). The retry status is published first, so the free tier and Go limit dialogs fire exactly as they do today, then Cause.done lets the error reach halt in the processor and the session goes idle. Waits inside the ceiling are untouched, so normal 429 and 5xx backoff behaves as before.

How this relates to the other open PRs on the issue, since the duplicate bot flagged them:

• fix(session): stop retrying free and Go usage quotas #47339 stops on the free_tier_limit and account_rate_limit reasons, which are derived from zen specific markers in the response body. That covers zen, but a provider that just answers with a long retry-after and no recognizable body still hangs the same way. This PR gates on the wait itself, so it covers that case too. The two are not exclusive, they compose fine if you want both.
• fix(cli): stop run from sleeping through an exhausted quota #42340 fixes the reporting side in run and is independent of this.

I hit this through a subagent, which is where it hurts most: the retry status is published on the child session ID, and both the TUI and the app ignore session.status for sessions other than the routed one, so the parent turn shows a spinning task tool and no dialog at all. Two of my sessions sat like that for 9h26m and 8h52m before I noticed.

How did you verify your code works?

Free tier actually exhausted, isolated XDG_DATA_HOME, same command both times:

bun dev run -m opencode/muse-spark-1.3-contributor-free "say pong"

• without the change: no output at all, killed by timeout 120
• with the change: Error: Rate limit exceeded. Please try again later., exit 1, 3.8s

Two new tests in packages/opencode/test/session/retry.test.ts, one per side of the ceiling. The first one fails on dev and passes with the change. bun test test/session/ gives 415 pass and bun typecheck is clean, both run from packages/opencode.

Screenshots / recordings

Not a UI change.

Checklist

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

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Found 2 potentially related PRs:

1. fix(session): stop retrying free and Go usage quotas #47339: fix(session): stop retrying free and Go usage quotas

   • fix(session): stop retrying free and Go usage quotas #47339
   • Related: Addresses stopping retries for free tier and Go usage exhaustion scenarios

2. fix: restore Go signup prompts and stop free-tier retries #46994: fix: restore Go signup prompts and stop free-tier retries

   • fix: restore Go signup prompts and stop free-tier retries #46994
   • Related: Also tackles free-tier retry handling and related dialogs

3. fix(cli): stop run from sleeping through an exhausted quota #42340: fix(cli): stop run from sleeping through an exhausted quota

   • fix(cli): stop run from sleeping through an exhausted quota #42340
   • Related: Similar issue with sessions sleeping/waiting when quota is exhausted

These PRs appear to address related concerns around stopping long waits during rate limiting and quota exhaustion scenarios. PR #47339 in particular seems closely aligned with the current PR's goals around free tier and Go limit handling.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[xam1986]

test

[ApexMene]

Thanks for the thorough review!

Applied both non-blocking notes in f258440:

• Clamped published next to wait > RETRY_MAX_WAIT ? now : now + wait so the status never advertises an attempt that won't be scheduled.
• Clarified RETRY_MAX_WAIT comment to distinguish it from RETRY_MAX_DELAY and point to policy().

Verified with bun test test/session/ (415 pass) and bun typecheck (clean) from packages/opencode.