Preset roster health scan is uncached — one un-mountable preset plus a retrying client pegs a core at 100%

[xrk-hhh]

Preset roster health scan is uncached — one un-mountable preset plus a retrying client pegs a core at 100%

Version: 0.1.5-alpha.1, source build (pnpm run build), Windows 11, Node 24.18.0
Symptom: the Web UI feels laggy (settings included) and the dsh web node process holds ~100% of one CPU core indefinitely — measured 9.5 s of CPU per 10 s of wall time, sustained for the whole session.

What happens

A third-party preset (router-standard, from a plugin repo) fails to mount because its persona row still carries the pre-rename config field:

agent-presets: preset "router-standard" failed to mount:
failed to apply loader entry persona (@deepseek-ai/dsh-persona): invalid config:
- $.prefix missing required value (at prefix)

The client that has that session open then retries the resume continuously (~25 retries/s). Every retry walks the full path:

ApiSessionAgentController.resumeObserved (packages/api/session-controller/src/agent.ts:414)
→ composeAgent (:374) → preset.resolve (packages/preset/agent-presets/src/index.ts:343)
→ list() (:248) → discoverPresets (packages/preset/agent-presets/src/discovery.ts:331)
→ scanRoot (:292) → compositionProblem (:225) → unresolvableRows (:194) → one existsSync per composition row.

discoverPresets caches nothing: each call re-reads and re-health-checks every preset directory and every row of every preset. A CPU profile of the burning process attributes ~37% of samples to existsSync and ~35% to unresolvableRows.

Why it matters

• One un-mountable preset becomes a permanent CPU burn whenever a client keeps that session open; the whole UI degrades — this is what a user experiences as "dsh is laggy", not as a preset error.
• Nothing in the loop is bounded: no backoff on a repeatedly failing mount, no caching of the roster scan, and the scan cost scales with the number of preset rows.
• With the client closed (--no-open, no page connected) the same server sits at ~0.3% CPU, so the burn is client-cadence-driven.

Possible directions (not prescriptive)

1. Cache/version the roster health scan (invalidate on root mtime change) so a resolve does not re-walk every row.
2. Back off or cap repeated failed mounts per session instead of retrying at client cadence.
3. Surface the mount failure in the UI — a session whose preset cannot mount currently just looks unresponsive.

Happy to attach the raw .cpuprofile and the instrumentation logs if that helps.