T

jschoubben 5b111da4a9 The patient reconnect gives up on permanent failures (issue 058 review)

The retry loop treated everything but a cert-pin mismatch as transient,
so a refused login (revoked/mis-sealed credential) or a malformed broker
URL retried for ever logging 'not reachable yet' — the silent
non-progress the fix set out to remove, and a contradiction of its own
docstring. fatalBrokerReason now classifies those three as fatal and
everything else (connection refused, timeout, DNS) as retryable, with a
unit test covering the split — the honest proof the bed cannot give,
since it only ever starts the consumer after the broker is up.

The pin case is now a typed PinMismatchError caught by instanceof, not a
prose substring a reword could silently downgrade to an infinite retry
against an impostor. Added a little jitter so modules do not stampede a
recovering broker in lockstep.

2026-09-20 13:30:52 +02:00

src

The patient reconnect gives up on permanent failures (issue 058 review)

2026-09-20 13:30:52 +02:00

test

The patient reconnect gives up on permanent failures (issue 058 review)

2026-09-20 13:30:52 +02:00

.gitignore

mesh-tools — the tool runtime and AMQP broker binding

2026-09-03 23:21:01 +02:00

dlxprobe.mjs

runtime: connect with a sealed credential, scoped, over pinned amqps (ADR 0048)

2026-09-04 01:51:17 +02:00

Dockerfile

Resolve the SDK in a throwaway deps stage, not with a buildkit secret

2026-09-16 11:48:16 +02:00

module.json

Build and run are two images, from one recipe

2026-09-14 01:57:05 +02:00

package.json

Resolve the SDK by version from the registry, not from a git URL

2026-09-16 10:27:26 +02:00

README.md

Resync hq ADR references 0044-0054 -> 0039-0049 after the hq record reconciliation

2026-09-05 12:45:25 +02:00

tsconfig.json

mesh-tools — the tool runtime and AMQP broker binding

2026-09-03 23:21:01 +02:00

README.md

mesh-tools

The Novox Mesh tool runtime — the per-node process that makes a module's tools actually serve.

A module ships its tools (built on @novox/mesh-sdk); this runtime is what loads them and puts them on the mesh. It:

connects the mesh broker (novox/hq ADR 0001) — a concrete AMQP implementation of the sdk's Broker contract;
imports the assigned modules' compiled tool entrypoints, each of which registers its tools as it loads;
serves them through the sdk's serveTools harness, answering tools.invoke over the broker.

Everything hard — dispatch, collection, duplicate-name safety — is the sdk's. This is the thin wrapper that binds the broker and loads the modules. Keeping the AMQP client here, out of the sdk, is deliberate: a broker-client change never rebuilds a module (ADR 0039).

Running it

MESH_BROKER_URL     amqp://…              the mesh broker
MESH_TOOL_MODULES   /a/tools/index.js,…   the assigned modules' compiled tool entrypoints

node dist/main.js, or the container (Dockerfile). On a node the host resolves both variables and starts it like any other supervised workload.

Verified

npm test stands up LavinMQ (the mesh's broker) and proves the whole path over real AMQP: the runtime serves a registered tool, a separate connection invokes it by name and gets the result, and an unknown tool is refused over the wire.