ERROR：本轮运行失败DeepSeek request extension preparation failed REQUEST_EXTENSION

[yyy6park]

repo 更新到最新版， clean build 后出错。貌似只有DeepSeek模型会出现这问题，其他的LLM不受影响。请问有什么解决办法吗？

[argszero]

The REQUEST_EXTENSION error is coming from a fail-closed resolver in the DeepSeek request-extension path, and your observation that "only DeepSeek models are affected" is the key diagnostic — the extension that throws is DeepSeek-specific.

Where it throws. packages/llm/llm-deepseek/src/adapter.ts:628 wraps prepareExtensions() and re-labels any throw as REQUEST_EXTENSION ("DeepSeek request extension preparation failed"). prepareExtensions is wired at llm-deepseek/src/index.ts:465-468 to call ctx.get('deepseekLlmApiExtensions')?.prepare(request). That registry's prepare iterates every registered extension provider, including the built-in dsh_plugin_packages one.

The actual failing resolver. packages/llm/plugin-package-inventory-deepseek/src/index.ts:117:

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

The dsh_plugin_packages extension's prepare (line 191-197) calls collectActivePluginPackages → resolver.resolve(activeEntry) for every active non-structural Loader entry. resolve throws the moment a bare package name can be parsed (barePackageName at line 53-58 returns a name for anything not ./:-prefixed/absolute) but no package.json manifests resolves at any of the search anchors (the barePackageManifest walk at line 72-83). That throw propagates up through collectActivePluginPackages → prepare → prepareExtensions, and the adapter flattens it to REQUEST_EXTENSION.

Why only DeepSeek. The deepseekLlmApiExtensions request-extension service is consumed only by the DeepSeek provider's chat path (llm-deepseek/src/adapter.ts:621). Every other LLM provider never calls prepareExtensions, so a thrown extension prep only ever surfaces as REQUEST_EXTENSION on DeepSeek requests. Non-DeepSeek "works" because the throw never gets exercised.

Likely trigger + fix direction. This is the same fail-closed-over-throw shape as a known family of plugin-package-inventory issues — the resolver throws on an unresolvable active package instead of degrading to "no identity for this entry." Typical triggers are package-manager layouts where the active package's package.json isn't findable from the host's Node search paths (e.g. pnpm/turborepo isolated node_modules, or a source-tree module directly loaded as a package), or a stale/broken fallback symlink. Because this is a best-effort inventory contribution (it only tells the model which packages are active), per-entry resolution should degrade gracefully — return undefined for the entry and continue — rather than throw the whole request.

Workaround for now. If you don't need dsh_plugin_packages in the request, this extension is config-controlleable: plugin-package-inventory-deepseek's config has an enabled flag — setting it false makes apply() return early (index.ts:187 if (config.enabled === false) return) so dsh_plugin_packages never registers and prepare never throws. That should restore DeepSeek model requests while a proper per-entry-degradation fix is upstream.

If you can share the full error (the cause shown in the console, or the package name in the message before cannot resolve active package), I can confirm exactly which trigger class you're on.