[Bug] dsh-plugin-manager: one hung operation wedges the profile for every later install/remove, and the market reports it only as a spinner

[FBIwar]

Summary

PluginManager.change() holds a package.json file lock for the whole mutation and
waits up to lockWaitMs (default 120 000 ms) for it; the HMR runExclusive
queue that the same call enters has no timeout at all. When a mutation hangs once
(e.g. the plugin market's pre-fix add name@version path, below), the profile stays
unusable: every later install/remove waits the full 120 s, and the market's own
mutation guard answers 409 another install is already running — the UI just spins.

Code

dsh/node_modules/@deepseek-ai/dsh-plugin-manager/lib/index.js

• :2373-2401 — change() wraps the whole operation in
  withFileLock(join(this.profile.dir, "package.json"), …, { waitMs: this.lockWaitMs })
• :1991 — update path rejection: if (this.ownerContext.get("hmr") !== void 0 && known !== void 0 && Object.hasOwn(before, known)) throw new ManagementFailure("already-installed");
• :1373-1379 — specPackageName() returns the bare name for a registry spec, so
  add foo@2.0.0 for an already-installed foo is refused before pnpm runs
  (pre-fix market 1.66.28 sent exactly that for updates: lib/routes.js:4322-4324)

dsh/node_modules/@deepseek-ai/dsh-hmr/lib/index.js

• :748-756 — runExclusive() chains work onto this.operations with no deadline and
  no cancellation; one task that never settles blocks every later request.

dsh/node_modules/@deepseek-ai/dsh-atomic-write/lib/index.js

• :189-218 — withFileLock() creates <file>.lock with the holder PID, retries, and
  throws atomic-write: timed out waiting for the writer lock at … after waitMs.
  The holder PID is only checked for liveness, so a live-but-stuck host is retried for
  the full two minutes on every call.

Reproduction

1. Start the app, let it install a plugin that changes the tool set (the market's own
   update attempt is enough) and leave the session open.
2. Trigger an update for any installed package from the market. On 1.66.28 this dies
   with {"code":"already-installed"} and then attempts a rollback.
3. Observe ~/.dsh/profiles/desktop/package.json.lock containing the live host PID,
   package.json/pnpm-lock.yaml rewritten, and no pnpm child process alive.
4. Every later update/uninstall now waits ~120 s and fails; the market log shows
   update-rollback … restoration of the previous build could not be verified.

Market log excerpt (~/.dsh/profiles/desktop/.dsh-market/log.ndjson):

{"event":"update","detail":"dshmarket -> dshmarket@1.66.45 exit=1 err={\"code\":\"already-installed\"}"}
{"event":"update-rollback","detail":"… failed update command and restoration of the previous build could not be verified — {\"code\":\"already-installed\"}"}
{"event":"uninstall","detail":"… exit=0 live-removed=false"}

Expected

• A bounded wait with an actionable error, not a two-minute silent stall.
• A stale/unresponsive lock holder reclaimed (PID + process start time, or a heartbeat),
  since the holder is the host itself and cannot make progress.
• The market UI surfacing the failure instead of an endless spinner.

Suggested fixes

1. Bound runExclusive and the lock wait, and surface a distinct profile-busy error.
2. Detect a lock whose holder is the same host process but whose operation is gone
   (lease/heartbeat) and break it.
3. Make the update path remove-then-install (this is what market 1.66.45 now does in
   installOrReinstall(), dshmarket/lib/official-desktop.js:150-178), so
   already-installed cannot be produced for an upgrade.

Local workaround used

Deleted the stale package.json.lock, upgraded the market to 1.66.45 with pnpm, and
added the new market version to pnpm-workspace.yaml minimumReleaseAgeExclude
(pnpm 11's 24 h release wait applies to the profile's lockfile, so upgrading to a
freshly published version otherwise makes every later pnpm operation fail with
ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION).

---

[PerryLink]

Your asymmetry is the right way to describe it: one of the two waits is bounded and the other is not.

change() enters both, and only the file lock has a deadline:

// packages/boot/plugin-manager/src/index.ts:852
return hmr === undefined ? apply() : hmr.runExclusive(apply)
// :903 / :925
return withFileLock(join(this.profile.dir, 'package.json'), async () => { ... }, { waitMs: this.lockWaitMs })

lockWaitMs defaults to 120000 (:212). runExclusive in packages/boot/hmr/src/index.ts:268-276 is a promise chain with no timer at all:

const task = this.operations.then(async () => { ... return this.executing.run(true, operation) })
this.operations = task.catch(() => {})
return task

this.operations advances only when the previous task settles, and a task that never settles parks the queue permanently. So after one hung mutation, every later change() waits on the queue before it even reaches the 120 s lock wait — which is why the market's 409 another install is already running looks like the lock is stuck when the lock is not involved yet.

Two things worth separating in the report:

• The 120 s lock bound does not protect the queue. Whatever hung the first operation is still holding it, and the second caller never gets to the point where the bound applies.
• runExclusive is also the queue used by automatic reloads (:278-282), so a wedged mutation stops HMR reloads too, not just installs.

The smallest fix that restores the property you expected: wrap the queued operation in a timeout inside runExclusive (or let change() pass an abort signal and race it), so a hung task rejects and the chain advances. Making the hung operation itself abortable is better but depends on what it is waiting for — the pre-fix market add name@version path you cite is a separate bug, and a queue timeout would at least stop one of them from taking the profile down with it.