A node holds the one module it cannot compose and applies the rest, as its shadow already answers (group fix/1126-apply-culprit, issue 1126) #118

Merged

mesh-tools merged 1 commits from fix/1126-apply-culprit into main 2026-10-28 16:34:46 +00:00

Conversation 1 Commits 1 Files Changed 6

+562 -70

1 Commits

Author	SHA1	Message	Date
jschoubben	0de3006415	A module refused alone is held, composed as what runs of it, on the node that applies as in its answer: one rule for both paths (issue 1126) ... The applying path (frombus.Compose) composed with no culprit, so one module's refusal came back as the whole node's: novox's apply would have refused all its modules for de-spiegel's unset route names. composeEach is now the one rule Compose and Answer both follow: - a module whose stub changes the refusal is held (compose.Node.Held); in the applying path a stand-in for a module placed here holds that module; only a refusal of no single module refuses the node; - a held module is composed from what runs of it (compose.Carried of its own composition in Running) and carried in the node's own wherever that runs it, folded or leaving the fold, so the node's own apply never removes it (issue 1945 by a new path) and what the others read of it is what runs; - none of a held module's own composition is in what is applied; - a module whose composition differs when the held ones are composed as stubs is held too; the node's own differing refuses the node; - since a held module is composed from its new manifest, what reads that manifest is held with it: the providers of what it contributes to (the proxy its routes) and, when it listens, the filter's holder. Quick fix weighed: a culprit loop in Compose alone. Thorough, chosen: one shared function, since the kind met twice (seed-8 shadow, now the apply), and review rounds 1 and 2 found its leaks.	2026-10-28 17:22:35 +01:00