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

Aperta
  • Qualcosa non va?
#30 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
api, backend

Direzione di ricerca

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.

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

Descrizione

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；③ 明确文档说明哪些路由支持"获取可用模型"。

Lingua principale
jq
Stelle
147
Fork
18
Nessuna PR unita negli ultimi 30g

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

Tutte le issue di volcengine/ark-cli

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.