bug: user-facing error discards the provider's reason, only shows "Provider returned error"
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start with the chat task's error-handling path described in the issue and trace how the provider response becomes the message error and UI bubble text. Verify the handling of error.metadata.raw and the generic error.message. Done means the user-facing error includes the actionable provider reason when it is present, without addressing auto-retry behavior.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Python
- Stars
- 570
- Forks
- 79
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-webui/computer
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
open-webui/computer#286 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
open-webui/computer#276 · 1 comment · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
open-webui/computer#271 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-webui/computer#269 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
open-webui/computer#250 · 1 comment ·
All issues in open-webui/computer
Similar issues
-
area: harness bug status: needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Human-Agent-Society/reef#625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 80/100
learningequality/kolibri#15351 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Name consistency Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
eellak/triplestore#65 · 1 comment ·