Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

bug: user-facing error discards the provider's reason, only shows "Provider returned error"

Aperta Adatta ai principianti
#293 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Inizia dal percorso di gestione degli errori del task di chat descritto nell’issue e segui come la risposta del provider diventa l’errore del messaggio e il testo del fumetto della UI. Verifica la gestione di error.metadata.raw e del generico error.message. Il lavoro è completato quando l’errore mostrato all’utente include il motivo utilizzabile del provider quando presente, senza intervenire sul comportamento di auto-retry.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
570
Fork
79
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di open-webui/computer

Tutte le issue di open-webui/computer

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.