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

Offen
  • Stimmt etwas nicht?
#1,301 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
backend-api-design, full-stack

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Rust
Sterne
3.7k
Forks
349
Ø Merge
2 T. 14 Std.
Gemergte PRs (30 T.)
97

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Open-Less/openless

Alle Issues in Open-Less/openless

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.