fix(session): cap retry attempts to prevent infinite thinking on API errors - #38958
fix(session): cap retry attempts to prevent infinite thinking on API errors#38958UCASRMTG5D wants to merge 1 commit into
Conversation
Sorry, something went wrong.
…errors Add RETRY_MAX_ATTEMPTS = 5 so the retry schedule terminates after ~60 seconds of backoff (2+4+8+16+30s). Without this cap, errors marked isRetryable (such as HeaderTimeoutError from nvapi) cause Effect.retry to loop forever, keeping the session stuck in 'thinking' state indefinitely. When the cap is reached the error propagates to the processor's halt handler, which sets the session to idle and publishes a Session.Event.Error so configured fallback chains can take over. Fixes anomalyco#38951
|
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:
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. |
Sorry, something went wrong.
Issue for this PR
Closes #38951
Type of change
What does this PR do?
When a provider returns a timeout error (e.g. HeaderTimeoutError from nvapi), the error is converted to an APIError with isRetryable: true. The session processor wraps the LLM stream with Effect.retry(SessionRetry.policy(...)), but since the error remains retryable indefinitely, the retry schedule never terminates — the session stays stuck in "thinking" state forever.
This PR adds RETRY_MAX_ATTEMPTS = 5 to the retry policy. After ~60 seconds of backoff (2s → 4s → 8s → 16s → 30s) the schedule gives up, the error propagates to the processor halt handler, the session transitions to idle, and a Session.Event.Error is published so configured fallback chains can take over.
How did you verify your code works?
I traced the full error propagation path through the code:
The diff is minimal: one new constant and one guard check.
Screenshots / recordings
N/A
Checklist