Provider HTTP error body never reaches the UI ('Check failed 400' with no reason)

Aperta
#1,301 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust

Direzione di ricerca

Start by tracing how provider errors flow from Verify and runtime polishing into the UI; the issue does not name files or tests. Check how polish failures fall back to raw transcripts and where capsule or history status is represented. Done means provider error messages are visible and skipped or raw-fallback polish is clearly indicated.

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

Descrizione

Environment: OpenLess 2.0.2-Beta.3+build.20261026-c9f49c60, macOS 27.2 arm64.

Two symptoms with the same root cause: the HTTP error body never reaches the user.

a) "Check failed 400" with no reason

The channel Verify showed only Check failed 400. The actual cause was a capitalised model name — the provider said exactly what was wrong, but only in the log:

DeepSeek API 400: "The supported API model names are deepseek-flash, deepseek-v4-pro,
but you passed Deepseek-chat."
b) Polish failures fall back to raw silently

When polish fails, the raw transcript is inserted with no visible notice. The product silently degrades to verbatim dictation, which to the user looks like the AI feature does not exist at all. This is the most confusing failure mode I hit.

Expected
  • Surface the provider's error.message in the UI on Verify and at runtime.
  • Show a small badge on the capsule / history entry whenever polish was skipped or fell back to raw.
Lingua principale
Rust
Stelle
3.7k
Fork
349
Merge medio
2g 14h
PR unite (30g)
97

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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-Less/openless

Tutte le issue di Open-Less/openless

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.