A module held for a missing secret gets no runtime of its own, so it never refuses its node's whole composition (issue 774) #142

Merged

mesh-tools merged 1 commits from fix/held-module-and-assigner-contract into main 2026-10-30 21:17:38 +00:00

Conversation 3 Commits 1 Files Changed 5

+103 -8

1 Commits

Author	SHA1	Message	Date
jschoubben	eff81f1220	Never refuse a node for a held module's stand-in by its own runtime's rules (issue 774) ... On 2026-10-30 at 21:04 mesh-self-check (ace) and mesh-conditions, mesh-healers (novox) were placed before their bus accounts were issued. Each was held for "needs a secret called broker and none was made"; its bare stub then lost its own secrets and was refused by ownRuntimes ("runs as its own account and declares no own secret broker"), a refusal no culprit takes, so 74 modules on ace and 79 on novox failed. A held runtime's stub met the same kind earlier today ("its build produced 0 bundle(s)"). Quick fix: let the bare stub keep its broker own secret, for this one rule. Thorough fix (chosen, the fourth of the kind today): a held module's stand-in (Stubbed) has no runtime composed at all, so no rule about its runtime, bundle or broker can refuse it: ownRuntimes passes it over and runtimeProcess composes none for a held runtime (what runs of either is carried, as before). A module of its own account left without its runtime by a held runtime is refused with a typed NoRuntimeToRunError, which makes the held runtime the culprit, so those modules are held after it and the node composes the rest.	2026-10-30 21:18:06 +01:00