Bug: stale broken fallback symlink (@deepseek-ai/dsh-storage-json) breaks every DeepSeek request after 0.1.2-alpha.3 upgrade

[Simon-panda]

Bug: stale broken symlink in profile module-fallback makes every DeepSeek request fail with "request extension preparation failed"

Summary

After upgrading deepseek-harness to 0.1.2-alpha.3, every DeepSeek model request fails with:

dsh: REQUEST_EXTENSION: DeepSeek request extension preparation failed

Root cause: plugin-package-inventory-deepseek (enabled by default) fails to resolve the
package identity of one active plugin entry — @deepseek-ai/dsh-storage-json — because
its symlink under the shared profile module-fallback ($DSH_HOME/profiles/node_modules) is a
stale broken symlink left over from the pre-upgrade dependency graph. healProfilesModuleFallback
never repairs or removes it, and the inventory plugin treats the lookup failure as fatal for the
whole request.

Environment

• DSH version: 0.1.2-alpha.3 (upgraded in place from an older checkout)
• OS: Windows 11
• Node: v22.22.0
• Layout: profile module fallback — $DSH_HOME/profiles/node_modules (shared) mirrors the
  installation dependency closure; profiles load their plugin tree through healProfilesModuleFallback.

Reproduction

node --import tsx/esm apps/cli/src/bin.ts --profile headless "reply ok"
# → dsh: REQUEST_EXTENSION: DeepSeek request extension preparation failed

(The same failure occurs in the web profile, which is how it was first observed.)

Precise failure point

Instrumenting the real headless loader and running plugin-package-inventory-deepseek's
per-entry PackageIdentityResolver.resolve() over all 85 active non-group entries yields
exactly one failure:

FAIL @deepseek-ai/dsh-storage-json: cannot resolve active package "@deepseek-ai/dsh-storage-json"
     (treeBase=file:///C:/Users/ASUS/.dsh/profiles/headless/)

The failing lookup is barePackageManifest() →
createRequire(anchor).resolve.paths(packageName) → existsSync(join(searchPath, packageName, 'package.json')).

The shared fallback symlink is broken:

$HOME/.dsh/profiles/node_modules/@deepseek-ai/dsh-storage-json
  -> /…/deepseek-harness/apps/cli/node_modules/@deepseek-ai/dsh-web-app/node_modules/@deepseek-ai/dsh-storage-json
  (mtime 2026-08-14 15:03  — created BEFORE the upgrade; target no longer exists)

A healthy neighbour for contrast (re-created after the upgrade at 2026-09-02 20:31):

$HOME/.dsh/profiles/node_modules/@deepseek-ai/dsh-storage
  -> /…/deepseek-harness/apps/cli/node_modules/@deepseek-ai/dsh-web-app/node_modules/@deepseek-ai/dsh-workspace/node_modules/@deepseek-ai/dsh-storage

Why the symlink is stale

resolveModuleFallbackEntries() (packages/boot/app-boot/src/profile.ts) builds the fallback
entry set by BFS over the dependency graph from apps/cli/package.json (the install anchor).

@deepseek-ai/dsh-storage-json is declared as a dependency of dsh-base (and
session-controller, message-feedback, session-projection-cache, subagent) — i.e. it is
reached through the profile bundle layer, not through the apps/cli dependency closure.
After the upgrade it is no longer reachable from the install anchor's BFS, so it is absent
from resolveModuleFallbackEntries()'s result.

healProfilesModuleFallbackLocked() only iterates the current entries (creating/repairing
those symlinks) and never removes symlinks that are no longer in the entry set. The
pre-upgrade symlink therefore survives, still pointing at the old (now non-existent) path.

The entry still activates in the loader (Node resolves @deepseek-ai/dsh-storage-json via the
workspace source package packages/storage/storage-json), so the plugin is present and ACTIVE —
but plugin-package-inventory-deepseek's independent existsSync-based lookup walks the
profile fallback directory and hits the broken link.

Why this takes down every request

plugin-package-inventory-deepseek/src/index.ts — resolve() throws on the failed lookup:

manifest = barePackageManifest(packageName, anchors)
if (manifest === undefined) {
  throw new Error(`plugin-package-inventory-deepseek: cannot resolve active package ${JSON.stringify(packageName)}`)
}

DeepSeekLlmApiExtensionRegistry.prepare() runs Promise.all over all registered providers,
so the throw propagates. llm-deepseek's adapter wraps it as
LlmError('DeepSeek request extension preparation failed', 'REQUEST_EXTENSION') — a hard
failure of every chat/completions request, before any HTTP dispatch.

Two distinct defects

1. healProfilesModuleFallback leaks stale symlinks. It has no sweep for entries that
   dropped out of the resolved dependency closure, and moduleFallbackEntryCurrent() compares
   only readlinkSync(link) === entry.packageDir (a path-string equality) without checking that
   the target actually exists. After a dependency-graph change, stale broken links accumulate
   and are never repaired or removed.

2. plugin-package-inventory-deepseek is fail-closed on a diagnostic field. A single
   unresolvable package identity aborts the entire request. Since this field (dsh_plugin_packages)
   is optional/observability-only, a failed lookup for one entry should degrade gracefully
   (skip that entry, or omit the field) rather than fail the model request.

Suggested fixes

• In healProfilesModuleFallbackLocked (or its caller), remove any symlink under the shared
  fallback node_modules that is not present in the current entry set (or at least any that is
  broken — lstat is a symlink but stat/existsSync fails).
• In moduleFallbackEntryCurrent, for kind === 'symlink', also verify the target exists
  (existsSync(join(entry.packageDir, 'package.json'))), so a broken link is treated as stale
  and healed.
• In plugin-package-inventory-deepseek, treat an unresolvable individual entry as a skip (or
  log-and-continue) rather than throwing, so an observability field can never take down the
  whole request path.

Workaround (applied locally)

Disable the plugin in each profile's cordis.patch.yml:

- id: plugin-package-inventory-deepseek
  disabled: true

This restores all DeepSeek requests. It sacrifices the dsh_plugin_packages diagnostic field,
not any functional behaviour.

[argszero]

Outstanding diagnosis — I verified both defects end-to-end against the current alpha sources (repo HEAD 4e84901 = 0.1.2-alpha.4), and this thread is actually the fourth report in a known family. Line anchors below.

Defect 2 confirmed, and it's a known family. plugin-package-inventory-deepseek/src/index.ts resolve() throws at :116-118 when barePackageManifest() returns undefined for a bare package, and — important detail — the throw happens before the cache write at :126, so nothing is memoized: every request re-resolves and re-throws. The caller side is deepseek-llm-api-extensions/src/index.ts prepare() :111-114, which fans out with Promise.all over every registered provider — one rejection aborts the whole request before HTTP dispatch, exactly as you traced. This same fail-closed resolver (same throw points, :116/:65-66) already took down whole request paths in #5172 / #5173 / #5196 — those were source-layout / pnpm isolated-layout resolution misses; yours is a third trigger class (stale module-fallback symlink) hitting the identical seam. The fix direction from those threads also converges here: per-entry degrade (skip an unresolvable identity and omit the field, log-and-continue) rather than throwing, because dsh_plugin_packages is observability-only. Four independent trigger classes on one fail-closed seam is a strong argument for that degrade being a real fix, not a workaround.

Defect 1 confirmed, with one design nuance your fix should account for. healProfilesModuleFallbackLocked (packages/boot/app-boot/src/profile.ts :595-605) only iterates the current entry set and never sweeps links outside it. But note the guard above it: moduleFallbackCurrent() (:553-555) is entries.every(...) — it only checks that every required entry is current, so stale extras alone never make it return false, and the locked heal body doesn't even run on a launch where all current entries are healthy. Your suggested sweep therefore can't live only inside healProfilesModuleFallbackLocked — a launch with no missing entries never reaches it. It needs to be either (a) part of the moduleFallbackCurrent decision (a "no stale owned links under the shared fallback" clause), or (b) an unconditional cheap sweep after the locked heal. Sweep scope should be conservative: only remove entries whose lstat is a symlink and whose package name is absent from the current entry set — never touch real directories (the comment at :573-575 says pnpm-managed entries in the profile's own node_modules remain authoritative, and a profile-owned dir carries bundle-only packages).

On moduleFallbackEntryCurrent (:535-550): your target-existence suggestion is right, and there's a second latent gap worth fixing in the same touch — the symlink comparison is raw readlinkSync(link) === entry.packageDir string equality with no resolve(), unlike symlinkPointsTo() (:283-284) which resolves the link text against the link's directory. A link whose stored text is relative, or whose target dir moved but the entry is still required, would compare unequal (harmless: heal recreates) or — with an added existsSync alone — could false-negative/positive depending on how packageDir is expressed. Comparing canonicalized paths (realpathSync on both sides when the target exists) would make the "current" check robust for both the stale case and the moved-install case.

One more observation on your root-cause narrative: you're right that the stale link is leftover from the pre-upgrade graph — resolveModuleFallbackEntries (:497-532) BFS-walks only the apps/cli closure, and bundle-carried packages like dsh-storage-json are supposed to live in the profile-local dir via healProfileModuleFallback (:591), not the shared fallback. So the shared-fallback link for it was always vestigial after the graph stopped listing it at the anchor level; the missing sweep is what let it survive into breakage.

Net: your workaround (disable the plugin) is sound and loses only the observability field. For upstream, the two fixes are independent and both small: (1) inventory per-entry degrade (also closes #5172/#5173/#5196), (2) stale-symlink sweep wired into the current-check or run unconditionally, with target-existence + canonicalized comparison. If you open a PR for either, I'm happy to review the shape against these anchors.