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

Aberta
#1,301 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
52/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Rust
Estrelas
3.7k
Forks
349
Merge médio
2d 14h
PRs com merge (30d)
97

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Open-Less/openless

Todas as issues de Open-Less/openless

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.