Problem (one or two sentences)
Errors raised by the upstream model provider after streaming has started are not propagated to the extension. Instead of the real provider error, the user sees a generic the model did not provide a response.
Context (who is affected and when)
Affects users on the Zoo managed gateway and the Vercel AI Gateway provider whenever the provider fails mid-response (rate limits, upstream server errors, content filtering, timeouts, etc.). The failure is logged on the gateway side but never reaches the extension UI.
Reproduction steps
- Environment: Zoo Code extension on the Zoo or Vercel AI gateway, any streaming-capable model.
- Send a request that triggers an upstream provider error after the response has begun streaming (e.g. exhaust a provider rate limit so the provider returns
429 Too many requests).
- Observe the extension shows only a generic "no response" error, while the gateway logs show the actual provider error message.
Expected result
The extension surfaces the provider's actual error message, following the same path as HTTP-thrown errors (including the Zoo gateway sign-in / add-credits / budget prompts where applicable).
Actual result
The extension shows error, the model did not provide a response and the real provider error is silently dropped.
App Version
v3.58.1
API Provider (optional)
OpenAI Compatible
Relevant logs or errors (optional)
Too many requests, please wait before trying again
Technical root cause (for the linked PR #569): Once a gateway response begins streaming, the HTTP status is already committed as 200, so the provider reports failures as an in-band error chunk ({ error: { message, status?, code? } }) rather than a thrown HTTP error. zoo-gateway.ts and vercel-ai-gateway.ts only read chunk.choices[0]?.delta and ignored chunks containing an error, so the stream ended empty. openrouter.ts already guards this with an if ("error" in chunk) check; these two handlers did not.
Problem (one or two sentences)
Errors raised by the upstream model provider after streaming has started are not propagated to the extension. Instead of the real provider error, the user sees a generic
the model did not provide a response.Context (who is affected and when)
Affects users on the Zoo managed gateway and the Vercel AI Gateway provider whenever the provider fails mid-response (rate limits, upstream server errors, content filtering, timeouts, etc.). The failure is logged on the gateway side but never reaches the extension UI.
Reproduction steps
429 Too many requests).Expected result
The extension surfaces the provider's actual error message, following the same path as HTTP-thrown errors (including the Zoo gateway sign-in / add-credits / budget prompts where applicable).
Actual result
The extension shows
error, the model did not provide a responseand the real provider error is silently dropped.App Version
v3.58.1
API Provider (optional)
OpenAI Compatible
Relevant logs or errors (optional)
Technical root cause (for the linked PR #569): Once a gateway response begins streaming, the HTTP status is already committed as
200, so the provider reports failures as an in-band error chunk ({ error: { message, status?, code? } }) rather than a thrown HTTP error.zoo-gateway.tsandvercel-ai-gateway.tsonly readchunk.choices[0]?.deltaand ignored chunks containing anerror, so the stream ended empty.openrouter.tsalready guards this with anif ("error" in chunk)check; these two handlers did not.