[BUG] "Fetch available models" fails on every route: Ark /models rejects x-api-key (401), postpaid baseURL yields 404

Aberta
  • Algo errado?
#30 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
javascript
Domínio
api, backend

Direção de pesquisa

Start by reading the provider route definitions and the model discovery adapter used by the plugin; the report names the anthropic-messages plan routes and postpaid routes with a /api/v3/compatible base URL. Check how discovery builds its authentication header and URL, then verify the expected /models paths and behavior against the route configuration. Done means discovery succeeds where supported, or the unsupported routes are clearly documented and the UI guidance matches.

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

Descrição

Summary

@volcengine/[email protected] on DeepSeek Harness Desktop 0.2.1-rc.2: the plugin loads correctly, the Ark providers appear in Settings → Models, and inference works — but "Fetch available models" (获取可用模型) fails on every route this plugin registers, even with a valid API key.

The reported 401 is misleading: the key is valid. The discovery request uses the wrong auth header for Ark's /models endpoint.

Environment

  • macOS (Apple Silicon), DSH Desktop 0.2.1-rc.2 (bundled Node 24.21.0, pnpm 11.28.5)
  • @volcengine/[email protected], installed into the desktop profile
  • Routes visible in Settings → Models: Ark Agent Plan, Ark Coding Plan, Ark Coding Plan (BytePlus), Ark (后付费), Ark BytePlus (后付费)

Steps to reproduce

  1. Install: dsh plugin --profile desktop add @volcengine/ark-plan-api and restart DSH.
  2. Settings → Models → Ark Coding Plan → paste a valid Ark Coding Plan API key → Save.
  3. Click Fetch available models (获取可用模型).

Actual

https://ark.cn-beijing.volces.com/api/coding/v1/models?limit=1000 answered 401; check the API key

Expected

HTTP 200 and a model list (Ark returns 137 models for this key).

Evidence — same key, only the auth header differs

Request Result
GET /api/coding/v1/models?limit=1000 + Authorization: Bearer <key> 200 (137 models)
GET /api/coding/v1/models?limit=1000 + x-api-key: <key> 401 the API key or AK/SK in the request is missing or invalid
GET /api/coding/v1/models?limit=1000 + both headers 200
POST /api/coding/v1/messages + x-api-key: <key> 200 (inference OK)
POST /api/coding/v1/messages + Authorization: Bearer <key> 200

Conclusion: Ark's /messages accepts both auth styles (so the key and the route are fine), but Ark's /models only accepts Authorization: Bearer.

Root cause

DSH's bundled @deepseek-ai/dsh-llm-pi-ai builds the model-discovery request per API style:

  • for api: anthropic-messages it sends x-api-key only (source comment: "Anthropic Messages uses x-api-key");
  • the discovery URL is ${baseURL minus trailing /v1}/v1/models?limit=….

Because this plugin declares api: anthropic-messages for the plan routes, discovery is sent with x-api-key, which Ark's /models rejects with 401.

Second, separate problem: postpaid routes hit a non-existent discovery path

The postpaid routes declare:

baseURL: https://ark.cn-beijing.volces.com/api/v3/compatible

so discovery requests https://ark.cn-beijing.volces.com/api/v3/compatible/models → 404.
Ark's OpenAI-compatible model list lives at https://ark.cn-beijing.volces.com/api/v3/models → 200 (verified with the same key).

If /compatible is required for inference, this route has no correct discovery path at all.

Impact

  • Only model discovery is broken. The model picker and inference work, because every provider's model list is already statically declared in the bundle's cordis.patch.yml.
  • The UX is still damaging: the UI says "check the API key", so users conclude their key is invalid and cannot diagnose it. Related: #28 (plugin not visible at all on 0.2.0-rc.2 — different symptom; on 0.2.1-rc.2 the providers do appear and inference works).

Suggested fixes

  1. Plan routes (anthropic-messages): make model discovery authenticate with Authorization: Bearer (or send both headers) for these providers. If the adapter does not allow per-provider discovery overrides, document that "Fetch available models" is unsupported on plan routes and that the predeclared model list should be used instead (ideally disable/hide the button for those routes).
  2. Postpaid routes: consider baseURL: https://ark.cn-beijing.volces.com/api/v3 (drop /compatible) so /models discovery resolves; otherwise document discovery as unsupported for this route.
  3. Docs: state explicitly which routes support model discovery, since the model list is already declared and discovery is optional.

Notes

  • Upstream DSH hard-codes the discovery auth header and discards the non-2xx response body (answered 401; check the API key), so the real Ark error is invisible to the user. A DSH-side improvement would be to surface the body. deepseek-ai/deepseek-harness has Issues disabled (Discussions only), so this is not filed there.
  • No credentials are included in this report; requests were made locally with the reporter's own key.

中文摘要

@volcengine/[email protected] + DSH Desktop 0.2.1-rc.2：插件生效、Ark provider 可见、对话推理正常，但「设置 → 模型 → 获取可用模型」在所有路由上都失败。

  • key 本身有效：用 Authorization: Bearer 请求 https://ark.cn-beijing.volces.com/api/coding/v1/models?limit=1000 返回 200（137 个模型）；/api/coding/v1/messages 也是 200。
  • 401 的真正原因：DSH 的 dsh-llm-pi-ai 对 api: anthropic-messages 的 provider 做模型发现时只发 x-api-key，而 Ark 的 /models 只接受 Authorization: Bearer（实测 x-api-key → 401；两种头同时发 → 200；但 /messages 两种头都接受）。
  • 后付费路由另有问题：baseURL 是 .../api/v3/compatible，模型发现请求 .../api/v3/compatible/models → 404；Ark 的 OpenAI 兼容模型列表在 .../api/v3/models → 200。

建议：① plan 路由的模型发现改用 Authorization: Bearer（或两种头都发），若不支持则在文档中说明并用内置模型列表；② 后付费路由 baseURL 考虑去掉 /compatible；③ 明确文档说明哪些路由支持"获取可用模型"。

Linguagem predominante
jq
Estrelas
149
Forks
19
Nenhum PR com merge em 30d

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 volcengine/ark-cli

Todas as issues de volcengine/ark-cli

Issues semelhantes

Mais issues de Backend & API Design

Receba novas issues na sua caixa de entrada

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