[asr] 火山引擎「新版控制台 API Key」模式下界面显示「未配置」,但实际可正常识别

Aperta
#1,071 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Soham-o ci sta già lavorando.

Dal 13/9/2026.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust, tauri
Ambito
backend

Direzione di ricerca

No file is named. Start by searching the Rust backend for where the struct carrying asrConfigured, volcengineConfigured and arkConfigured is built, then compare it side by side with the runtime path that loads providers from the credentials.v1.chunk.0.com.openless.app vault. The suspected divergence is the authMode branch: in api_key mode the check should be true when volcengineApiKey is set and lastTest.ok is true. Confirm which field the overview badge binds to, fix the branch, and cover both api_key and APP ID/Access Token modes in a test; done when a volcengine provider in api_key mode shows 已配置.

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

Descrizione

现象

  • 触发条件:ASR 提供商选用火山引擎,鉴权模式为「新版控制台 API Key」,填入 API Key 后。

  • 当前表现:概览页 ASR 卡片右上角显示灰色「未配置」徽标(同页 LLM 卡片正常显示绿色「已配置」)。但 ASR 实际工作完全正常。

  • 证据:

    1. 界面截图:ASR 卡片显示「火山引擎 bigasr / volcengine」+「未配置」;LLM 卡片显示「DeepSeek / deepseek」+「已配置」。

    2. 凭据保险库(credentials.v1.chunk.0.com.openless.app,UTF-16LE JSON)中该 provider 的实际内容:

      "version": 2,
      "active": { "asr": "foundry-local-whisper", "llm": "ark" },
      "providers": {
        "asr": {
          "foundry-local-whisper": {
            "providerType": "volcengine",
            "order": 0,
            "lastTest": { "ok": true, "latencyMs": 278, "at": 1789227388 },
            "authMode": "api_key",
            "volcengineApiKey": "<已设置>"
          }
        }
      }
      

      注意 lastTest.ok = true,即连接测试已通过,却仍判定未配置。

    3. 运行日志证明链路完全可用(火山识别 → DeepSeek 润色 → 文本插入):

      [coord] recorder started (asr=volcengine, phase=Starting)
      [coord] ASR connected; flushed 3520 deferred audio bytes
      [asr] server JSON: {"audio_info":{"duration":10250},"result":{"text":"我是看到...","utterances":[...]}}
      [style-pack] llm polish assembled provider=deepseek model=deepseek-flash mode=Structured
      [llm] POST https://api.deepseek.com/v1/chat/completions provider=deepseek model=deepseek-flash
      [llm] HTTP 200 body={...,"content":"我看到在工具..."}
      
    4. 直接对端点做 WebSocket 握手,同一把 API Key 返回 101 Switching Protocols:

      GET /api/v3/sauc/bigmodel_async   Host: openspeech.bytedance.com
      X-Api-Key: <API Key>   X-Api-Resource-Id: volc.seedasr.sauc.duration
      → HTTP/1.1 101 Switching Protocols
      

      而换用 volc.bigasr.sauc.duration 则返回 403 {"error":"[resource_id=...] requested resource not granted"} —— 可反证 seedasr 资源在该账号下确已开通。

  • 判定字段:后端下发给前端的结构里含 asrConfigured、llmConfigured、omniConfigured、volcengineConfigured、arkConfigured。该徽标应由 asrConfigured / volcengineConfigured 驱动。结合 lastTest.ok=true 仍显示未配置,判断为状态判定逻辑与运行时凭据读取逻辑不一致。

  • 一个可能的成因(未验证,供参考):volcengineConfigured 的判定可能未按 authMode 分支,在 api_key 模式下仍去检查旧版控制台必填的 APP ID / Access Token 字段;而运行时凭据加载逻辑是按 authMode 正确分支的,因此出现「能用但报未配置」。

  • 另一处可疑点(同源但独立,若被认为应拆分请告知):保险库中 active.asr 指向的键名为 foundry-local-whisper、active.llm 指向 ark,但两条记录的 providerType 分别是 volcengine 与 deepseek —— 键名与实际类型不同步(应为在既有 provider 条目上直接更改类型所致)。LLM 那条同样是旧键名却显示「已配置」,故此项可能不是该徽标的成因,但一并报告以免遗漏。

影响

  • 用户无法通过界面判断 ASR 是否配好,与 lastTest 的成功结果直接矛盾,会引导用户反复重新填写 API Key 或去改安全组/资源包,浪费排查时间。
  • 本次排查中确实因此产生误判——一度认为是密钥或服务未开通问题。
  • 属于「界面状态与实际能力不一致」的误导性反馈,非功能故障。

建议接受标准

  • 火山引擎在 authMode = "api_key" 时,只要 volcengineApiKey 已填写且 lastTest.ok = true,asrConfigured / volcengineConfigured 即为 true,概览页显示「已配置」。
  • 判定逻辑与运行时凭据读取逻辑使用同一套「按 authMode 分支」的条件,不再出现二者结论相反的情况。
  • 新增/修改 provider 时,键名与 providerType 保持同步(或在读取时以 providerType 为准,不依赖键名)。

TODO / 不确定项

  • 未能读取前端源码确认徽标具体绑定的是 asrConfigured 还是 volcengineConfigured(前端资源为压缩嵌入,环境无 brotli 解压能力)。上述绑定关系为根据字段名推断。
  • 「判定未按 authMode 分支」为推测,未定位到具体代码,需维护者确认。
  • 未确认旧版控制台模式(APP ID + Access Token)下是否同样显示「未配置」——本人账号未创建旧版应用,无法对照。该对照实验能直接区分上述两个候选成因,建议优先做。
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.