Host-side: plugin market unloaded after every install/uninstall (and a host-written patch row can block the next start)

[ikemono]

Host-side: the plugin market is unloaded after any install/uninstall (and never remounted); a host-written patch row can block the next start

Environment

• DSH Desktop 0.2.1-rc.2 (win-x64, Electron), Windows 11
• dshmarket 1.69.0 (also reproduced on 1.66.44 / 1.67.0)
• pnpm 11.28.5 (bundled runtime)

Problem 1 — install/uninstall leaves the market unloaded

1. Install or uninstall any plugin from the market;
2. pnpm completes successfully;
3. the host replays the profile's plugin set, which tears down the market (its client part
   is in the replay too) and does not mount it again;
4. the page shows “插件市场已停止运行”, GET /dsh-market/status → 404;
5. refreshing does not help; only a full DSH restart recovers.

The dsh-market maintainer confirmed this is the official desktop host's replay behavior and
that nothing inside the market package can prevent it (same family as dsh-market #900/#962).

Problem 2 — a host-written dangling patch row can block the next boot

After an uninstall that dies mid-way, cordis.patch.yml keeps a host-written row:

- id: pet
  name: "@linxin666/dsh-pet"
  config:
    visible: true
    size: 160
    right: 260
    bottom: 302
    petId: whale-girl

The package and its dependency are gone, but the row still references it. DSH boot is
all-or-nothing, so this row makes the next start fail — and the host exits before mounting
any plugin, so no in-app recovery surface is reachable.

The maintainer confirmed that rows of this id + name + config shape are written by the
host's own install dialog / config layer, not by the market, so the market's uninstall does
not remove them; only a process outside the plugin tree can.

Expected

• The host should drop rows whose package no longer exists before composing (or treat them
  as inert rather than fatal);
• a recovery surface outside the plugin tree should let the user remove such rows and retry;
• problem 1 would be much better if the market were remounted after the replay.

Workarounds used today

• restart DSH after every install/uninstall;
• when the boot is blocked, delete the rows that reference uninstalled packages from
  cordis.patch.yml (safe once the package is gone).

[ikemono]

Update from our side — the original repro no longer happens on dsh-market 1.70.1.

Environment: Desktop 0.2.1-rc.2 (unchanged), dshmarket 1.70.1, Windows 11.

• update of an installed plugin (dsh-context 0.74.0 → 0.75.1) through the market: pnpm exit 0, activation.state = "restart", /dsh-market/status stayed 200 across 20 polls — no unload;
• install of @changfenhuang/dsh-genui 0.14.0: the market log now shows the host's own replay activated it; adopted instead of mounting a second copy (#814, #827) and exit=0 hot=true;
• uninstall of the same package: uninstall-start is now followed by a completion entry (exit=0), where the 1.67.0 run stopped at uninstall-start;
• no 404, no restart needed, and no row left behind in cordis.patch.yml (cleanup removed the dependency, the node_modules entry, and the row).

So the "market is unloaded after install/uninstall" half was not reproducible for us on 1.70.1, even though the host is the same 0.2.1-rc.2 — the plugin-side replay adoption plus the 1.70.x changes appear to cover it.

What we have not re-tested is the host-written row shape (- id: X + name + config) that can still block the next boot when its package disappears; the recovery surface outside the plugin tree still looks like the missing piece for that case.

Thanks — happy to run further probes on this host if useful.