[Bug] pluginManager.updateBundle (HMR) re-activates dsh-web-app's directory-picker-auto and fails with duplicate "directoryPicker" service

[Mars-Sea]

Environment

• @deepseek-ai/dsh 0.2.2-rc.1 (npm-installed), Node 24.22.1, pnpm 12.8.1
• Fresh isolated DSH_HOME, web profile created with --from-default-profile web
  (so dsh-base + dsh-web-app; HMR enabled by default through the hmr row)
• Third-party bundle installed as a registry spec: dsh-deeppilot@0.9.15
• Target version dsh-deeppilot@0.9.16 (published, declares dsh.bundle, engines.dsh compatible)

Reproduction

1. Install the plugin into the profile with dsh plugin --profile <p> add dsh-deeppilot@0.9.15.
   The resulting package.json holds a registry spec and dsh.profile.bundles includes the name,
   so listBundles() marks it updatable.

2. The plugin's bundle patch (cordis.patch.yml) does the following, because a phone client cannot
   interact with a native OS picker rendered on the host:

   - id: directory-picker
     disabled: true
   
   - insert:
       - id: deeppilot-directory-picker-browse
         name: "@deepseek-ai/dsh-host-directory-picker-browse"
       - id: deeppilot-directory-picker-browse-client
         name: "@deepseek-ai/dsh-client-ui-directory-picker-browse"
       - id: deeppilot
         name: "dsh-deeppilot"
         config: {}

3. Start dsh <profile>. Confirm the plugin is active and host.listDirectory works.

4. Trigger an update through the public service:
   pluginManager.updateBundle('dsh-deeppilot', '0.9.16', { registry, requestId }).
   (In our case the call is driven by a phone client over an authenticated WebSocket, but the
   failure is entirely inside the host's plugin manager.)

Observed

pnpm add dsh-deeppilot@0.9.16 succeeds. installBundle then returns:

{
  "step": "install",
  "result": {
    "application": "failed",
    "stage": "enable",
    "error": {
      "code": "operation-error",
      "diagnostic": "dsh: warning: 1 entry did not activate\ndeeppilot-directory-picker-browse (@deepseek-ai/dsh-host-directory-picker-browse): Error: service \"directoryPicker\" has been registered at <NativeDirectoryPicker>"
    }
  },
  "restore": {
    "application": "failed",
    "error": { "code": "operation-error", "diagnostic": "… same duplicate-service error …" }
  }
}

Net effect: the target version is installed, then removed; the previous version is re-installed;
the update is reported as a failure. Reproduced twice in two independent DSH_HOMEs (different
volumes, different requestIds), so it is deterministic, not an environment artifact.

Root cause (as far as we can tell from the shipped code)

dsh-web-app composes the directory-picker row as
@deepseek-ai/dsh-host-directory-picker-auto. That plugin samples the host once at boot and mounts
the matching backend and client surface via ctx.loader.create() into the in-memory root tree;
its disposer removes both and awaits their fibers. On a local macOS host with a loopback bind it
chooses native, so NativeDirectoryPicker registers ctx.directoryPicker.

With HMR enabled, updateBundle performs removeBundle(name) → installBundle(name@version).
During the intermediate composition the bundle layer is gone, so the disabled: true patch on
directory-picker disappears and -auto re-activates, mounting the native backend. When the
bundle layer is re-added, the inserted -browse row tries to register directoryPicker while the
native instance is still registered. Cordis rejects duplicate services, the host turns
"1 entry did not activate" into application: 'failed', and the restore path hits the same
collision.

This matches the -auto package README ("Fixing an interaction is not a config field: compose
-native or -browse directly in place of this row … mounting the selector together with a
backend row explicitly errors, duplicate directoryPicker service"). The problem is that the
update's two-step replace exposes a composition state that is never reachable on a cold boot.

Why it is not the package or the network

• dsh plugin --profile <p> add dsh-deeppilot@0.9.16 followed by a host restart starts cleanly
  (serverVersion 0.9.16, all rows active, host.listDirectory works).
• listVersions('dsh-deeppilot') returns listed with the target compatible.
• The check phase of updateBundle passes; only the online enable step fails.

Suggested fix

Make the remove→install transition atomic with respect to composition: do not let lower-layer rows
re-activate in the intermediate state. For example, hold the outgoing bundle's patch layer until the
incoming one is installed, then compose the final tree once and hand it to HMR; or compute the final
composition first and only apply the delta. If an online replace is inherently unsupported for
bundles that replace a service row, it would help to detect that case and return
restart-required instead of failed + rollback.

Verified workaround

Disabling the hmr row in the profile's cordis.patch.yml makes updateBundle take the no-HMR
branch (install over the running version, restart-required). With that change:

• host.listDirectory keeps working (the browse backend stays mounted),
• apply reports restart-required, the profile ends up on 0.9.16,
• after a host restart the plugin runs 0.9.16 and the durable update journal resolves to done.

So the whole self-update flow is functional; only the HMR online-replace path is affected.

Evidence available on request

plugin-manager pnpm logs for the remove/install/restore runs, the full updateBundle return
object, the composed config dump (--dump-config), and the phone-side wire frames. Happy to attach
redacted copies.

[PerryLink]

The remove-then-install window is real; HMR triggers it.

plugin-manager/src/index.ts:713 is updateBundle. With HMR present it announces removing, calls removeBundle(name) at :756, then installs the target. The doc comment above the method states the same sequence. During that window the bundle layer is gone, so your - id: directory-picker / disabled: true row is gone too; directory-picker-auto re-activates and mounts the native backend. When the new layer arrives, -browse tries to register directoryPicker and Cordis refuses the duplicate. The restore path repeats the same remove/install, so it hits the same collision.

packages/host/directory-picker-auto/README.md:40 states the same rule: mounting the chooser and a backend row together fails loud with a duplicate directoryPicker service.

Workaround: run the update with HMR out of the picture. dsh plugin --profile <p> add dsh-deeppilot@0.9.16 with the host stopped applies the package change with no composition window at all; the next boot composes the new bundle once. Alternatively disable the hmr row for that update.

Without HMR, updateBundle takes the :749 branch and installs over the running version instead of removing it, so the composition never enters a state where the bundle layer is missing. That path is worth one test with your exact bundle before filing the issue, because it is the difference between "the update path is wrong" and "this patch cannot survive any update".

The structural part remains: a bundle patch that relies on a disabled row cannot survive a remove/install window, and updateBundle has no compose-before-remove step today.

[Mars-Sea]

Thanks — that matches what we measured, and we ran the three-way test you suggested with the
exact bundle before replying further.

Setup: fresh isolated DSH_HOME, three profiles created from --from-default-profile web
(dsh-base + dsh-web-app, so directory-picker = -auto), each installed as a registry spec
dsh-deeppilot@0.9.15, target 0.9.19 (current latest). Our bundle patch is unchanged from the
report: a disabled: true row on directory-picker plus an inserted
@deepseek-ai/dsh-host-directory-picker-browse backend and its client surface. Driven over the
authenticated phone WebSocket, so each apply is a real pluginManager.updateBundle call.

#	Profile	HMR	Update path	Result
1	pu-hmr	on	updateBundle	fails + rolls back. installBundle → application: 'failed', stage: 'enable', duplicate directoryPicker; restore fails with the same error. Journal failed, profile stays 0.9.15
2	pu-nohmr	off (hmr row disabled: true)	updateBundle	succeeds via restart. Progress restart-required; profile on disk 0.9.19; after a host restart serverVersion 0.9.19, journal done
3	pu-cli	on, but host stopped	dsh plugin --profile <p> add dsh-deeppilot@0.9.19	succeeds. No composition window; next boot composes once, serverVersion 0.9.19, no activation warnings

So to answer your framing: this is not "this patch cannot survive any update". Both
non-HMR paths apply the change and the disabled + insert pair survives intact — in scenario 2
and 3 host.listDirectory still returns a listing (s2c.directory.listing) after the update, i.e.
the browse backend is still the mounted one. Only the HMR remove → install window breaks it,
because that window is exactly the composition state where the disabled row is absent and -auto
re-activates.

Two follow-ups:

1. Is a compose-before-remove step (or a delta apply) on the roadmap for updateBundle?
   Scenario 1 is currently an update that always fails and rolls back for any bundle whose patch
   targets a row another plugin owns — the user sees a failure for an update that would have worked
   on the next boot. If it is not planned, please consider documenting that in the
   plugin-manager README next to updateBundle, so bundle authors know a disabled row makes
   the bundle "cold-update only" under HMR.
2. If online replace is inherently unsupported for such bundles, can it return
   restart-required instead of failed + rollback? That is actionable for a client: the update
   did land or would land on restart, and a restart-required result would avoid the
   remove/restore churn entirely. Our client already has a restart-required state (it is what
   scenario 2 reports), so this would be a clean, non-breaking improvement.

If it helps, the concrete detector for case 2 is cheap: during the install, a duplicate-service
failure from an entry that the incoming layer added — as opposed to the target package failing to
load at all — is the signal that this is a "needs cold compose" case rather than a broken package.
Happy to test a build that carries either change.

[PerryLink]

These are roadmap questions; I can only give the code path.

updateBundle is plugin-manager/src/index.ts:738. The HMR window is :786 (removeBundle) and :793-796 (failed enable → remove, then restore-install). At e8f7b93a there is no compose-before-remove branch in that sequence, so your scenario 1 follows from the code as written.

Whether a delta apply, a documented "cold-update only" note, or returning restart-required is planned is not something I can answer. Those are product decisions and I do not speak for the project.

What would make the report stronger: the ManagementError code scenario 1 returns. A duplicate-service failure from a row the incoming layer added is detectable inside installBundle before the remove, which is the hook your suggestion needs; an incompatible-version rejection is a different case.

Hand this to an AI assistant to draft the issue with that code included.

[Mars-Sea]

Thanks for checking the code path. The error code in our recorded DSH 0.2.2-rc.1 test was operation-error, at result.stage: 'enable'; it was not incompatible-version.

The original dsh-deeppilot@0.9.15 → 0.9.16 report already includes that error-code excerpt. Both result.error.code and restore.error.code were operation-error, and the diagnostics named this collision (excerpt below, with line wrapping normalized):

dsh: warning: 1 entry did not activate
deeppilot-directory-picker-browse (@deepseek-ai/dsh-host-directory-picker-browse):
Error: service "directoryPicker" has been registered at <NativeDirectoryPicker>

The target installation reached the enable stage after the package operation succeeded. Reinstalling the previous version also reported the collision. The profile returned to 0.9.15 on disk, which establishes disk restoration but does not establish that all runtime services recovered.

The later 0.9.15 → 0.9.19 three-way test is the separate follow-up summarized above: HMR enablement failed, whereas the no-HMR and stopped-host paths reached 0.9.19 and directory listing worked after restart. These are recorded 0.2.2-rc.1 results; we have not runtime-tested your referenced e8f7b93a commit.

I also need to correct my earlier “cheap detector” suggestion. managementError() at e8f7b93a maps ordinary errors to operation-error. Combined with the enable stage and duplicate-service diagnostic, this identifies an activation collision, but it does not establish that the collision is temporary or that the target would start successfully after a restart. A safe restart-required fallback would need stronger checks and a defined policy for retaining the target on disk; changing the result status alone would not be sufficient.

I have consolidated the tested package, recorded results and source references into an issue-style draft, with those limits stated explicitly. Happy to test a candidate fix.