Desktop plugin loader: hung imports time out, timers die on disable, duplicate ids error, broken reloads retire stale code

[teknium1]

Desktop runtime plugins can no longer freeze the plugin scan, leak timers past disable, silently steal each other's id, or keep stale code live after a broken save.

Four findings from a static + live-probe audit of apps/desktop/src/contrib/runtime-loader.ts (the <hermes home>/desktop-plugins/*/plugin.js door). No issues exist for these — they came from a code audit, not a report. Root cause for all four: the loader's error isolation ("a broken plugin can never take the app down / clean reload") held only for the happy path of register().

Changes

Finding	Before	After
Hung import	A plugin with a top-level await that never settles hangs import(); scanDiskPlugins awaits it in a sequential loop under a scanning re-entrancy guard, so every later folder never loads and every future poll/watch tick returns early — dead loader until restart.	import() races a 10 s deadline (IMPORT_TIMEOUT_MS). The plugin gets status:'error' (import timed out after 10s — module evaluation never settled) on its own row; the scan continues with the rest.
Timer / DOM leak on disable	Only registrations through ctx were disposed; bare setInterval / addEventListener survived disable and every hot-reload (a runaway poller keeps running after the user turns the plugin off).	PluginContext gains setTimeout / setInterval / addEventListener (contrib/plugin.ts::createPluginLifetime), tracked with the plugin and torn down on unload/reload/disable. Fired one-shots drop out of the set on their own; the host disposer is registered lazily on first use so plugins that never use them add nothing. SDK doc states bare globals are NOT tracked.
Duplicate id last-wins	Two folders exporting the same id both load; the second's activate disposes the first's registrations and overwrites its row, and each file's hot-reload flips ownership — silently, in unsorted readDir order.	First loaded owns the id; a later file with a different path errors on its own folder row: duplicate id "x", already loaded from <path>. Folder listing is sorted by name so ownership is deterministic across launches.
Stale incarnation after a broken reload	loadDiskPlugin kept entry.id and left the old module's contributions + activate handle live when a save no longer loaded (syntax error, now also timeout/duplicate). The Plugins tab showed the broken file as "loaded" beside a folder-named error row, and toggling re-ran stale code.	When the file no longer yields the previous id, the previous incarnation is unloaded and its row/handle dropped — the error row is the only row left.

Docs: website/docs/developer-guide/desktop-plugin-sdk.md — PluginContext block gains onDispose + the three scoped helpers; three new Pitfalls bullets (bare globals untracked, 10 s evaluation deadline, one id one file).

Validation

One invariant test per fix in runtime-loader.test.ts (loader hardening describe), A/B'd against origin/main sources with a cp swap:

Test	base	fix
hung import times out as its own error; later folder still loads	✗ (test itself hangs → 15 s timeout, i.e. the freeze)	✓
ctx.setInterval / ctx.addEventListener die on unload	✗	✓
duplicate id: first (sorted) wins, later errors on own row	✗	✓
broken save retires the previous incarnation	✗	✓

• npm run check:lint (typecheck + eslint): 0 errors.
• npx vitest run src/contrib/ src/sdk/: 124/124. Full desktop vitest run recorded below.

Not changed (out of scope, deliberately): scanDiskPlugins stays sequential — a hung plugin now costs at most 10 s per scan pass rather than a dead loader; a duplicate row stays error until its own next reload after the owner is removed (the next hot-edit or manual "Reload desktop plugins" clears it).

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 546d791 — fix(desktop): runtime plugin loader survives hung imports, l}

debug info

CI timings

CI timings · View report · View job

Wall time 6m27s vs 5m44s (+12.5%). 6 job(s) slower, 8 faster,

• Docs Site / docs-site-checks: -45.0s
• OS-specific tests / Windows-only tests: +29.0s
• Python tests / Run tests: +17.0s
• Python tests / e2e: -9.0s
• Python lints / Windows footguns (blocking): +9.0s