[GH-ISSUE #293] bug: user-facing error discards the provider's reason, only shows "Provider returned error" #206

New issue

Open

opened 2026-10-18 14:03:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:03:47 +00:00

Owner

Originally created by @Classic298 on GitHub (Sep 20, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/293

When an upstream provider fails, OpenRouter returns a structured error with the real reason in error.metadata.raw. Example from a live failure:

{"error":{"message":"Provider returned error","code":429,"metadata":{"raw":"z-ai/glm-5.3-flash is temporarily rate-limited upstream. Please retry shortly, or add your own key to accumulate your rate limits: ...","provider_name":"BaseTen","limit_source":"upstream_provider_shared_pool","remedy_hint":"Retry shortly, add your own provider key, or route to another provider"}}}

The chat task's error handling reads only error.message and stores that as the message error. So the chat shows:

Error: Provider returned error

That string carries zero actionable information: no rate limit, no provider name, no retry hint. The user cannot tell a transient 429 (retry in a minute) from a dead API key (needs settings) from a model outage (switch model). The full reason was in the response body and got dropped on the floor.

Suggested change: when building the error message, prefer error.metadata.raw over error.message when the message is the generic "Provider returned error" (or more generally, include the raw reason whenever metadata is present). Same for the error the user sees in the UI bubble.

Related: #188 asks for auto-retry on 429, which is a separate ask; this issue is only about surfacing the actual reason when the error is shown. #178 was an earlier report where the error stayed invisible.

Originally created by @Classic298 on GitHub (Sep 20, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/293 When an upstream provider fails, OpenRouter returns a structured error with the real reason in `error.metadata.raw`. Example from a live failure: ```json {"error":{"message":"Provider returned error","code":429,"metadata":{"raw":"z-ai/glm-5.3-flash is temporarily rate-limited upstream. Please retry shortly, or add your own key to accumulate your rate limits: ...","provider_name":"BaseTen","limit_source":"upstream_provider_shared_pool","remedy_hint":"Retry shortly, add your own provider key, or route to another provider"}}} ``` The chat task's error handling reads only `error.message` and stores that as the message error. So the chat shows: > **Error:** Provider returned error That string carries zero actionable information: no rate limit, no provider name, no retry hint. The user cannot tell a transient 429 (retry in a minute) from a dead API key (needs settings) from a model outage (switch model). The full reason was in the response body and got dropped on the floor. Suggested change: when building the error message, prefer `error.metadata.raw` over `error.message` when the message is the generic "Provider returned error" (or more generally, include the raw reason whenever metadata is present). Same for the error the user sees in the UI bubble. Related: #188 asks for auto-retry on 429, which is a separate ask; this issue is only about surfacing the actual reason when the error is shown. #178 was an earlier report where the error stayed invisible.

bsakaguchi referenced this issue

2026-10-18 14:04:37 +00:00

[PR #206] [MERGED] 0.9.18 #314