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

Ouverte
  • Quelque chose ne va pas ?
#30 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
javascript
Domaine
api, backend

Piste de recherche

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.

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

Description

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

Langage dominant
jq
Étoiles
147
Forks
18
Aucune PR mergée en 30 j

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

Toutes les issues de volcengine/ark-cli

Issues similaires

Plus d'issues Backend & API Design

Recevez les nouvelles issues par e-mail

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