fix(opencode): extract statusCode from error variants for 5xx retry

[okuyam2y]

Issue for this PR

Closes #19203

Type of change

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

What does this PR do?

Some OpenAI-compatible providers throw plain errors or objects instead of APICallError, so 5xx responses fall through to UnknownError and never retry. This extracts the status code from common error shapes so 5xx responses stay retryable.

How did you verify your code works?

Added unit coverage for the status extraction paths and negative cases. bun test test/session/message-v2.test.ts and bun run typecheck pass.

Screenshots / recordings

N/A — no 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:

Potential Related PRs

Found 2 related PRs that address similar retry logic issues:

1. PR fix(retry): retry transient 429 responses even when provider marks non-retryable #18443 - fix(retry): retry transient 429 responses even when provider marks non-retryable

   • fix(retry): retry transient 429 responses even when provider marks non-retryable #18443
   • Related: Also addresses retry behavior for provider error responses, specifically for 429 status codes

2. PR fix: retry on AI_TypeValidationError from provider 5xx responses #16228 - fix: retry on AI_TypeValidationError from provider 5xx responses

   • fix: retry on AI_TypeValidationError from provider 5xx responses #16228
   • Related: Handles retrying on 5xx errors from providers, similar error classification strategy

These PRs are not exact duplicates but address the same general area (session/retry error handling for provider responses). You may want to review them for potential conflicts or ensure consistency in the retry logic approach.

[github-actions]

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

[okuyam2y]

Rebased onto latest dev and squashed into a single commit. All 28 message-v2 tests pass, typecheck clean.

Changes from previous version:

• Adapted to upstream's errorMessage() helper (added in recent commits)
• Squashed 3 commits into 1 for cleaner history

Would appreciate a review when you get a chance. Happy to address any feedback.

[tim-mohrbach-ikigai]

Nice PR! This covers the most common error shapes well.

One edge case I have hit with OpenRouter: their error JSON uses code instead of status/statusCode:

{"code":502,"message":"Network connection lost.","metadata":{"error_type":"provider_unavailable"}}

The current JSON fallback checks obj?.status ?? obj?.statusCode ?? obj?.response?.status ?? obj?.response?.statusCode, which misses obj?.code. Adding it to the extraction would cover OpenRouter's format too:

const status =
  obj?.status ?? obj?.statusCode ?? obj?.code ??
  obj?.response?.status ?? obj?.response?.statusCode
if (typeof status === "number" && status >= 500) {

The metadata.error_type field (e.g. "provider_unavailable") could also be useful for classification, but just checking code for numeric 5xx values would already fix the OpenRouter case.

I logged this separately in #22448 — happy to close it as a duplicate if this PR ends up covering the code field.

[okuyam2y]

Good catch, thanks! I've added code to the extraction chain in all three branches (Error, JSON-encoded, plain object) and the ErrorWithStatus interface. Three new tests cover the OpenRouter format.

Updated in 4b4e18f. Also rebased onto latest dev.

@tim-mohrbach-ikigai feel free to close #22448 if this covers your case — or keep it open if you want metadata.error_type classification as a separate enhancement.