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

Ouverte
  • Quelque chose ne va pas ?
#1,071 5 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@Soham-o y travaille déjà.

Depuis le 13/9/2026.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust, tauri
Domaine
backend

Piste de recherche

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 已配置.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

现象

  • 触发条件：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）下是否同样显示「未配置」——本人账号未创建旧版应用，无法对照。该对照实验能直接区分上述两个候选成因，建议优先做。
Langage dominant
Rust
Étoiles
3.7k
Forks
349
Merge moyen
2 j 14 h
PR mergées (30 j)
97

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Open-Less/openless

Toutes les issues de Open-Less/openless

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.