Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
#293 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Comienza con la ruta de manejo de errores de la tarea de chat descrita en el issue y sigue cómo la respuesta del proveedor se convierte en el error del mensaje y en el texto de la burbuja de la UI. Verifica el manejo de error.metadata.raw y de error.message, que es genérico. Se considera terminado cuando el error visible para el usuario incluye el motivo accionable del proveedor cuando está presente, sin abordar el comportamiento de auto-retry.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
570
Forks
79
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de open-webui/computer

Todos los issues de open-webui/computer

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.