One SDK per runtime: a bundle's SDK import resolves to the runtime's copy (hq issue 209) #32

2026-10-03T10:44:33Z

mesh-admin commented

2026-10-03 10:44:33 +00:00

Found preparing hq design 38 WP4, before the first module's tools bundle is loaded beside the runtime's own.

A bundle carries its dependencies (to-be 38 WP3), the SDK among them. Imported in-process, that copy is a second SDK with its own tool registry: a bundle's registerModuleTools lands in a list the runtime never reads, the bundle counts as loaded, and tools answers an empty list — silently. Proven with a two-copies probe on the laptop (0 registrations seen).

Fix: node-tools installs a module.registerHooks() resolve hook (in-thread, synchronous; module.register() is deprecated from Node 26 — probed on 23.9, 25.8, 26.7 and 26.10, the four nodes' versions) before the first bundle is imported; every import of @novox/mesh-sdk (bare or a subpath), from whichever bundle, resolves against the runtime's own file, so there is one registry and one broker. Everything else a bundle carries still resolves from its own tree; a launched bundle (ADR 0188) is untouched.

Test: a bundle in a temp directory with its own copy of the SDK is served (zeta.probe@anchor answers). Without the hook the same test fails with serving 0 tool(s) for 1 module(s): (none). Full suite 33/33 against the test bus.

hq: 04-ISSUES/209 (hq #316). Follow-up: mesh-catalog #239 (WP4) merges only after this has rolled to all four nodes.

Found preparing hq design 38 WP4, before the first module's tools bundle is loaded beside the runtime's own. A bundle carries its dependencies (to-be 38 WP3), the SDK among them. Imported in-process, that copy is a second SDK with its own tool registry: a bundle's `registerModuleTools` lands in a list the runtime never reads, the bundle counts as loaded, and `tools` answers an empty list — silently. Proven with a two-copies probe on the laptop (0 registrations seen). Fix: `node-tools` installs a `module.registerHooks()` resolve hook (in-thread, synchronous; `module.register()` is deprecated from Node 26 — probed on 23.9, 25.8, 26.7 and 26.10, the four nodes' versions) before the first bundle is imported; every import of `@novox/mesh-sdk` (bare or a subpath), from whichever bundle, resolves against the runtime's own file, so there is one registry and one broker. Everything else a bundle carries still resolves from its own tree; a launched bundle (ADR 0188) is untouched. Test: a bundle in a temp directory with its own copy of the SDK is served (`zeta.probe@anchor` answers). Without the hook the same test fails with `serving 0 tool(s) for 1 module(s): (none)`. Full suite 33/33 against the test bus. hq: `04-ISSUES/209` (hq #316). Follow-up: mesh-catalog #239 (WP4) merges only after this has rolled to all four nodes.

jschoubben force-pushed fix/issue-209-one-sdk-per-runtime from d4a4f4d1ba to 5d395c5473

2026-10-03 10:49:43 +00:00

Compare

jschoubben added 1 commit 2026-10-03 11:00:22 +00:00

One SDK per runtime: a bundle's SDK import resolves to the runtime's copy (hq issue 209) 7152148410

A bundle carries its dependencies, the SDK among them; imported in-process that copy was a
second SDK with its own tool registry, so a bundle registered its tools into a list the
runtime never read and served nothing, silently. A resolve hook (module.registerHooks, in
thread; module.register is deprecated from Node 26) now sends every import of
@novox/mesh-sdk, from whichever bundle, to the runtime's own copy: one registry, one broker.
The test loads a bundle from a directory holding its own SDK copy and sees its tool served.

jschoubben force-pushed fix/issue-209-one-sdk-per-runtime from 5d395c5473 to 7152148410

2026-10-03 11:00:22 +00:00

Compare

mesh-admin merged commit 4537494150 into main

2026-10-03 11:07:08 +00:00

mesh-admin deleted branch fix/issue-209-one-sdk-per-runtime

2026-10-03 11:07:09 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-tools#32