Bug: directory-specifier loader rows fail every DeepSeek request with REQUEST_EXTENSION

[JawzoD3TH]

Summary

When a profile mounts a loader row whose name is a relative directory specifier (e.g. ./ext/dashboard-widgets, resolved by the Loader through its package.json main), the row activates and every DeepSeek model request in that process fails with:

DeepSeek request extension preparation failed  (code REQUEST_EXTENSION)

The failure persists for as long as that row is active, and the wrapper message hides the actual cause from both the UI and the session log (only message + code are persisted).

Environment

• App: dsh web profile with a separate DSH_HOME (second instance)
• Checkout commit: cd5ef81481, version 0.1.2-alpha.1
• OS: Windows, Node v24.13.0
• Affected package: @deepseek-ai/dsh-plugin-package-inventory-deepseek

Repro

1. Create a profile-side package with a valid manifest — package.json declaring name, version, and main, plus the module file (e.g. ./ext/dashboard-widgets, a clock widget package).
2. Mount it as a host row by directory specifier in the profile's cordis.patch.yml:

   - insert:
       - id: dashboard-widgets
         name: ./ext/dashboard-widgets

3. Send any message. The first request after the row activates fails with REQUEST_EXTENSION; every later request fails while the row stays active.

Observed in a real session log: turn 5 finished editing cordis.patch.yml (step 18), and the very next model request (step 19) — and every subsequent turn — died with REQUEST_EXTENSION.

Actual vs expected

• Actual: all requests fail with the wrapper error; removing the row (or restarting without it) is the only unblock.
• Expected: a directory-resolved package is attributed to its own manifest, requests continue, and the dsh_plugin_packages field reports the package's real identity.

Root cause

packages/llm/plugin-package-inventory-deepseek/src/index.ts — nearestManifest():

let current = dirname(modulePath)   // starts one level ABOVE modulePath

The inventory re-derives a row's module location from the raw specifier (new URL(entry.options.name, treeBase)), not from the Loader's own resolution. For a row that names a directory, modulePath is the package directory, so dirname() skips the package's own package.json and the ancestor walk climbs to the nearest manifest that happens to exist. In a profile that is the profile root's package.json (dsh-profile-web), which declares a name but no version — so identityFromManifest() throws:

plugin-package-inventory-deepseek: <…>/package.json must declare non-empty name and version

That throw propagates through collectActivePluginPackages() → DeepSeekLlmApiExtensionRegistry.prepare() → the DeepSeek adapter wraps it as REQUEST_EXTENSION. A single un-attributable active row therefore takes down the whole model route process-wide.

Fix and workaround

User workaround (no code change): reference the package's module file instead of the directory, or give the profile-root package.json a version:

- insert:
    - id: dashboard-widgets
      name: ./ext/dashboard-widgets/index.js

Root-cause fix (drafted, verified): nearestManifest() should check the path's own package.json before the ancestor walk, so a directory-resolved package is attributed to itself (./ext/dashboard-widgets → lab-dashboard-widgets@0.1.0) instead of an ancestor manifest. A regression test mounts a directory row whose own manifest is valid while its ancestor carries a name-only manifest:

• RED on the old code: reproduces the outage verbatim (must declare non-empty name and version)
• GREEN after the fix; full spec 12/12 pass

Files changed in the draft:

• packages/llm/plugin-package-inventory-deepseek/src/index.ts — nearestManifest() own-manifest check
• packages/llm/plugin-package-inventory-deepseek/tests/inventory.spec.ts — regression test

Recommended follow-ups (design decisions)

1. Resilience: the existing tests deliberately lock in "a malformed/unresolvable active package fails request preparation". Consider whether one un-attributable row should really fail every request process-wide (it produced a full instance outage). If not, make resolution per-entry tolerant (skip + warn) and keep the loud failure only for genuinely malformed, payload-relevant entries.
2. Diagnosability: the REQUEST_EXTENSION cause is swallowed — cause is not surfaced in the UI or the session log. Surfacing the cause chain would have turned this into a two-minute fix instead of a code dig.
3. client-modules (packages/client/modules/src/index.ts, nearestPackage) has the same ancestor-walk shape, but its primary path resolves through the Loader's resolveSync (a file URL), so directory rows are already attributed correctly there; only its no-internal fallback path shares the latent pattern and could be hardened the same way.

[JawzoD3TH]

From the second (offending) instance that caused the problem:
...That report is spot-on — and I can corroborate every part of it first-hand, because I'm the agent that made the offending edit. A few confirmations from my side:

The report matches the incident exactly. It's the same session where turn 5 finished editing cordis.patch.yml and the next request — and every one after — died with REQUEST_EXTENSION. I never saw that error surface in the UI/logs with its cause, which is precisely the "diagnosability" gap you flagged.

The mechanism checks out against the code I can read:

• identityFromManifest() (discussion 6064 quotes it) throws must declare non-empty name and version — and your profile-root D:\dsh-instances\lab\profiles\web\package.json really does declare name: "dsh-profile-web" with no version. So the ancestor walk landed exactly where you said.
• One notable update: the checkout we run against (D:\deepseek-harness) already contains your drafted fix — nearestManifest() now checks the path's own package.json before walking up (src/index.ts:96–99), with a comment describing the directory-specifier case verbatim. So if your report predates that landing, you may want to note it's no longer just a draft in the working tree.

The workaround you documented is also what unblocked us: pointing the row at ./ext/dashboard-widgets/index.js instead of the directory — and that's the form that persisted cleanly across the restart.

The two follow-ups you raised are the ones maintainers should hear: one un-attributable row taking down the whole model route process-wide is the real severity here, and swallowing the cause chain turned a two-minute diagnosis into a code dig.

[argszero]

@JawzoD3TH 这条跟一个已知家族的成员完全同构——我把它系到家族上，并补一个已经被社区多次确认的修复方向。

家族上下文

这是 plugin-package-inventory-deepseek 的 fail-closed throw 把一个应该可跳过的 entry 拖死整条官方 DeepSeek 路由 的典型。同样机理（本地/目录路径插件 → identityFromManifest 对 profile-bootstrap 容器 manifest 抛错 → 每请求 REQUEST_EXTENSION）此前已被多帖戳中：

• [Bug] Local file plugins in a profile make every official DeepSeek request fail with REQUEST_EXTENSION (profile package.json must declare non-empty name and version) #5844（2026-09-07）：profile 挂绝对路径本地插件 → 同样 REQUEST_EXTENSION。根因就是 identityFromManifest()（packages/llm/plugin-package-inventory-deepseek/src/index.ts:61-70）对顺着 nearestManifest 向上找到的 profile 容器 package.json（~/.dsh/profiles/*/package.json，有 name 无 version） 抛 must declare non-empty name and version。
• 更早的 ERROR：本轮运行失败DeepSeek request extension preparation failed REQUEST_EXTENSION #5683 / REQUEST_EXTENSION 报错把 cause 链完全吞掉：终端、会话日志、Web UI 三处都看不到真实原因 #5173 / Bug: stale broken fallback symlink (@deepseek-ai/dsh-storage-json) breaks every DeepSeek request after 0.1.2-alpha.3 upgrade #5439 也是同一根因链（resolve fail-closed + REQUEST_EXTENSION cause 被吞）。

你这帖的增量

你挂的是相对目录 specifier（./ext/dashboard-widgets）而非 #5844 的绝对路径——但两者落到同一个 throw：

• barePackageName('./ext/dashboard-widgets')（:53-58）以 . 开头 → 返回 undefined；
• 于是走 :119 的 else-if，new URL(name, treeBase) → nearestManifest 向上（:86-95）找到最近的那个 package.json；
• 关键：identityFromManifest(manifest, packageName === undefined) = identityFromManifest(manifest, true)——allowAnonymous 只容忍"没有 name"（return undefined），但若最近 manifest 是 有 name 无 version 的容器/profile 根，:64-66 仍会 throw。

所以哪怕你的 ./ext/dashboard-widgets 自己有完整 name+version，只要 nearestManifest 向上命中了一个 version-less 的容器 manifest，这一 entry 就会 throw，api-extensions/src/index.ts:111 的 Promise.all([...entries.map(...)]) 是全量 fan-out —— 任意一个 prepare 抛错 → 整个 prepareExtensions 失败 → adapter.ts:636 包成 REQUEST_EXTENSION → 官方路由全灭。

修复方向（家族共识）

per-entry 降级（fail-soft）：identityFromManifest 对"有 name 无 version"的最近 manifest 应该跳过该 entry 并记 warn（视为 no-identity），而不是 throw 一票否决整个请求。这是家族 6+ 帖的收敛结论，也和 REQUEST_EXTENSION 应只拦截"真不该带的请求"而非"某个 entry 解析不了"的语义一致。附带一个可观测性缺口：adapter.ts:636 的 LlmError 只 persist message + code，真实 cause 被吞（#5173 已单独立项）。

改法落到 identityFromManifest 一处即可（把 throw 换成一个返回 no-identity + 侧路 logger.warn），建议配一个回归用例：profile 挂相对目录插件 + 容器 manifest 无 version → prepare 应 resolves 而非 rejects.toThrow。这个修法只放大可接受面，不动其它 entry 的判定，是低风险的。

[JawzoD3TH]

Thanks @argszero — agreed on the family, and I've linked the four: #5844 (absolute-path local file plugin → profile container package.json with no version), #5439 (stale fallback symlink → unresolvable bare package), #5173 (the swallowed cause chain, already filed on its own), #5683 (the same symptom reported earlier).

Two notes on where the fix has to land:

My nearestManifest walk fix does not cover #5844. That plugin is a file with no manifest of its own, so the profile container package.json genuinely is its nearest manifest — checking the path itself first changes nothing there. The walk fix only covers directory specifiers, where the package's own manifest was being skipped entirely: my row now reports lab-dashboard-widgets@0.1.0 (As mentioned earlier) instead of throwing. So it's a data-correctness fix for one variant, not a fix for the family.

Fail-soft inside identityFromManifest alone does not cover #5439. That report never reaches identityFromManifest: with the broken symlink barePackageManifest() returns undefined, and resolve() throws cannot resolve active package "…" a few lines earlier. The site that covers the whole family is the per-entry collection — wrap each resolver.resolve(entry) in collectActivePluginPackages() and skip + warn on failure — with a lenient identityFromManifest as a second, narrower layer.

One caveat for whoever takes it: two existing tests assert the current fail-loud policy (fails request preparation for an active package with malformed identity metadata and fails when a Loader-resolved bare entry has no package manifest), so a fail-soft fix has to update them too — otherwise the next regression test just re-asserts the defect.