Responses stream rate_limit_error chunks crash with Type validation failed #18897

Description

Description

When OpenCode uses a provider/model path that goes through the Responses API, some rate limit errors are returned as a wrapped SSE chunk like this:

{"error":{"type":"rate_limit_error","message":"Concurrency limit exceeded for user, please retry later"}}

OpenCode 1.3.0 currently expects stream errors in a different shape, mainly with a top-level type: "error" event.

Because of that, this wrapped error chunk fails stream chunk validation and surfaces as a Type validation failed error instead of being converted into a normal retryable API error.

This looks related to rate limit handling, but the immediate bug is a Responses stream error-shape compatibility issue.

OpenCode version

1.3.0

Steps to reproduce

1. Use a model/provider path that goes through the Responses API
2. Trigger a concurrency or rate limit error
3. Receive a stream error chunk like:

{"error":{"type":"rate_limit_error","message":"Concurrency limit exceeded for user, please retry later"}}

4. Observe that OpenCode throws a validation error instead of treating it as a retryable provider error

Actual behavior

OpenCode reports an error like:

Type validation failed: Value: {"error":{"type":"rate_limit_error","message":"Concurrency limit exceeded for user, please retry later"}}

followed by a large Zod union validation failure.

Expected behavior

The wrapped stream error chunk should be accepted and normalized into a regular API error.

For rate_limit_error, it should ideally be marked retryable and flow into the existing retry logic instead of failing stream validation.

Notes

From local source inspection, the current Responses stream schema accepts:

• various response.* events
• top-level type: "error" chunks

but does not accept wrapped chunks in the form:

{"error": {...}}

So the failure seems to happen before normal API error/retry handling gets a chance to run.