Bug: dsh_plugin_packages — one unresolvable active package fails every deepseek-official request (REQUEST_EXTENSION)

[bululuburuarua666]

Symptom

When any active plugin package cannot be resolved to a readable package.json on disk, every request to a deepseek-official model fails with:

LlmError: DeepSeek request extension preparation failed   (code: REQUEST_EXTENSION)

The provider becomes completely unusable until the offending package is repaired — no request ever reaches the network.

Environment

DSH 0.1.5-rc.1 (the same code is still on master as of 2026-09-13).

Root cause

packages/llm/plugin-package-inventory-deepseek/src/index.ts — PackageIdentityResolver.resolve:

const packageName = barePackageName(entry.options.name)
let manifest: string | undefined
if (packageName !== undefined) {
  manifest = barePackageManifest(packageName, anchors)
  if (manifest === undefined) {
    throw new Error(`plugin-package-inventory-deepseek: cannot resolve active package ${JSON.stringify(packageName)}`)
  }
}

The throw propagates through DeepSeekLlmApiExtensionRegistry.prepare() (Promise.all over the registered contributors) → the adapter wraps it as REQUEST_EXTENSION → the whole model request dies before HTTP dispatch. There is no per-contributor isolation: one broken package poisons the dsh_plugin_packages field and therefore every official DeepSeek request.

Reproduction

1. Have a deepseek-official model configured and any third-party plugin mounted from a directory.
2. Break that package's on-disk layout (e.g. delete its package.json — in our case a third-party plugin updater deleted the package contents and failed to restore them, leaving a gutted directory).
3. Send any message with the official provider selected → every turn fails with the REQUEST_EXTENSION error.

Suggested fix

A diagnostic inventory field should never be able to take down a model request. Either:

• skip + warn: catch per-package resolution failures inside collectActivePluginPackages and log via ctx.logger.warn, continuing with the resolvable packages; and/or
• isolate per contributor: let the registry's prepare() treat a single contributor's rejection as "field omitted this request" (optionally with a warning), so one broken contributor cannot fail the others or the request itself.

[PerryLink]

Confirmed against master (dsh-v0.1.5-rc.2-139-gc291e7961a; the three cited files are byte-identical to rc.1). Mechanism is real: a bare package name that can't resolve throws in PackageIdentityResolver.resolve (plugin-package-inventory-deepseek/src/index.ts:117, existsSync at :79); collectActivePluginPackages (deepseek-llm-api-extensions/src/index.ts:170-176) has no per-package try/catch and runs on every request, so one broken package fails the whole prepare; the adapter wraps it as REQUEST_EXTENSION before any fetch (llm-deepseek/src/adapter.ts:627-637 vs fetch at :651, pinned by adapter.spec.ts:211-232). This is the documented contract (docs/subsystems/llm-streaming.md:742), not a regression; the existing escape hatch is plugin-package-inventory-deepseek enabled:false (config-catalog.md:1689-1692). Two refinements: only bare-name entries throw - relative/absolute path mounts resolve via nearestManifest and are skipped silently when missing (index.ts:119-123); and a proper fix would be warn-and-omit, e.g. a catch+warn per package in collectActivePluginPackages (pattern at packages/llm/llm/src/index.ts:375), updating adapter.spec.ts:211 and llm-streaming.md:742 together.

[PerryLink]

Confirmed — this is a real mechanism, and it is the documented contract rather than a regression. One broken active package does fail every deepseek-official request before any HTTP. I verified against c291e7961a (current checkout HEAD; the three cited files are byte-identical to the dsh-v0.1.5-rc.1 tag, per git diff), and the repo's own test suite passes at this commit (inventory 11/11, registry 7/7, adapter 157/157), including the tests that pin this exact behavior.

Root cause (verified)

The failure chain is:

1. packages/llm/plugin-package-inventory-deepseek/src/index.ts:112-118 — for a bare-name entry, barePackageManifest() searches Node's package search paths with existsSync (:79); if no package.json is found, PackageIdentityResolver.resolve throws cannot resolve active package "<name>". The same resolve also throws for a found-but-invalid manifest: unparseable JSON (identityFromManifest, :62) or missing/non-empty name+version (:66).
2. collectActivePluginPackages (:151-179) calls resolver.resolve(activeEntry) in a loop (:171-175) with no per-package try/catch, so the first failing package rejects the whole inventory collection, which is the prepare of the dsh_plugin_packages contributor (:190-197).
3. packages/llm/deepseek-llm-api-extensions/src/index.ts:108-129 — the registry's prepare() runs Promise.all over every registered contributor (:111). There is no per-contributor isolation: one rejection rejects the entire preparation for the request. This is pinned by registry.spec.ts:124-133.
4. packages/llm/llm-deepseek/src/adapter.ts:627-637 — the adapter awaits prepareExtensions (bound to the registry at llm-deepseek/src/index.ts:481-485) and wraps any rejection as LlmError('DeepSeek request extension preparation failed', 'REQUEST_EXTENSION', { cause }). HTTP fetch happens only later (:651), so the request dies with zero network traffic. Pinned by adapter.spec.ts:211-232 (asserts REQUEST_EXTENSION and server.requests length 0).

So yes: the inventory runs on every request (apply registers prepare per request, no result-level caching), the throw is re-attempted each time (failed resolutions are not cached), and Promise.all means the broken package poisons not only its own field but the whole extension transaction — deepseek-official becomes completely unusable until the package is repaired or the field disabled.

Impact scope (verified)

• Only deepseek-official is affected. The adapter registers that single provider route (llm-deepseek/src/index.ts:90,492), and llm-pi-ai does not consume this registry at all (deepseek-llm-api-extensions/README.md:32; no references in llm-pi-ai).
• Not every mount shape can throw. Relative/absolute/file-URL entries walk to their nearest manifest and are silently omitted when none is found (index.ts:119-123); only bare-name or package-subpath entries hit the :117 throw, plus any entry whose existing manifest is malformed or lacks name/version.
• This is documented, not accidental: docs/subsystems/llm-streaming.md:742 ("Preparation, collision, and acceptance failures use REQUEST_EXTENSION and fail the model request") and plugin-package-inventory-deepseek/README.md:38 ("malformed package metadata fails request preparation"). The strict behavior is intentionally pinned by inventory.spec.ts:97-103 and :161-170.
• Minor related detail: manifest identities are cached per process (index.ts:100); since failures are not cached, repairing the directory restores service on the next request, but replacing a cached package identity with a different version requires a restart (README "Known Limitations").

Diagnosis steps (for the reporter and future triagers)

1. Read the cause on the LlmError — it carries the original error naming the offending package: plugin-package-inventory-deepseek: cannot resolve active package "<name>", or ... must declare non-empty name and version, or a JSON parse error with the manifest path.
2. Fix the named package on disk (restore a package.json with non-empty name and version, or uninstall/disable the plugin row). The next request succeeds; restart if the package identity changed.
3. Immediate unblock without repairing the package: set enabled: false on the plugin-package-inventory-deepseek row in the composition. The row ships default-on in packages/bundle/base/cordis.patch.yml:70-71; the flag is documented in docs/config-catalog.md:1689-1692 and the plugin README. This drops the whole field, so it is a workaround, not a fix.

Suggested fix directions

1. Narrow (recommended): warn-and-omit per package. Wrap resolver.resolve(activeEntry) in collectActivePluginPackages with try/catch → ctx.logger.warn(...) → continue. An existing in-repo precedent is the contained-listener pattern at packages/llm/llm/src/index.ts:373-377. Update inventory.spec.ts:97-103 and :161-170 to assert warn-and-omit instead of rejection, and soften the README:38 statement.
2. Registry-level isolation. Change prepare()'s Promise.all to Promise.allSettled and omit a rejected contributor's field (optionally with a warning). Note the registry already uses tolerant settle-everything semantics for the acceptance phase (acceptAll, :41-48), so this would make preparation consistent with acceptance. However, the strict prepare is the documented contract (llm-streaming.md:742) and is pinned by adapter.spec.ts:211-232 and registry.spec.ts:124-133, and it changes semantics for every contributor (including dsh_session_log) — so this needs docs + tests updated together, and likely a per-contributor opt-in rather than a blanket behavior change.
3. Optionally combine with reducing request-time work (e.g. caching the collected inventory with invalidation on Loader/package changes), but that is an optimization — the correctness fix is #1 or #2. A diagnostic inventory field should never be able to take down a model request.

Unverified parts

• No live reproduction against a real deployment with a gutted third-party plugin directory (deliberately did not touch any local ~/.dsh); verification is static code reading plus the repo's own test suite executed locally at c291e79.
• "Still on master as of 2026-09-13" is only verifiable up to this checkout's HEAD (2026-09-10); anything merged after is out of reach from here.
• The third-party updater scenario (directory gutted by a failed update) is taken from the report as-is; the code path shows it is sufficient to trigger the failure, but that specific sequence was not replayed.

[bululuburuarua666]

Thanks @PerryLink — the confirmation is thorough, and the warn-and-omit direction plus the enabled: false escape hatch are both noted.

Real-world trigger, confirmed in production (2026-09-13): the "gutted directory" scenario is not hypothetical. On this deployment a third-party plugin updater did rm -rf before cp on @memtensor/memos-local-plugin; the copy aborted with EPERM on better_sqlite3.node (mapped by the running host), leaving the package with no package.json. From that moment every deepseek-official turn failed with REQUEST_EXTENSION — and the LlmError.cause did name the offending package exactly as your diagnosis steps predict. Restoring the package from its source tree (no host restart needed, since failed resolutions are not cached) made the next request succeed. So the chain runs end-to-end in the wild exactly as you mapped it.

Adopted your narrow fix as a local patch: per-package try/catch → ctx.logger.warn(...) → continue in collectActivePluginPackages. Verified in isolation: a broken bare-name entry now produces one warning and is omitted while the resolvable packages are still collected (e.g. ["dsh-better-sidebar@0.19.1"]). We are keeping the field enabled — it is useful diagnostics — with the patch carrying the resilience, rather than the enabled: false workaround.

If upstream takes the fix, the test/doc touch points you listed (inventory.spec.ts:97-103, :161-170, README:38) are exactly the ones I would expect to change together; happy to mirror whatever shape lands.