Delivery parts keep running when the bus refuses a bucket they can work without; the builder asks a lost build again; the assigner says why a node gets no want (issue 1945) #51

Merged

mesh-tools merged 4 commits from fix/1945-ask-again-and-why into main 2026-10-25 21:43:11 +00:00

Conversation 1 Commits 4 Files Changed 50

+1500 -253

4 Commits

Author	SHA1	Message	Date
jschoubben	4628ba26b4	Delivery parts: take the essential and optional bucket opens from mesh-sdk (issue 1945) ... The open helpers were copied into seven parts; code shared between modules lives in mesh-sdk, so they are mesh-sdk process's now and the parts are pinned at fix/1945-optional-buckets (e0d1de04), moved to its main once it merges, one delivery group with mesh-sdk.	2026-10-25 22:30:22 +01:00
jschoubben	20027e53ff	Delivery parts: a bucket the bus refuses at start stops a part only when it cannot work without it (issue 1945) ... Met twice on 2026-10-25: the builder of #48 exited on a refused read of the gate's source and crash-looped, and its new reasks bucket would have done the same. A grant reaches the bus with a delivery, so a refusal or a timeout at start is often only a grant not there yet; exiting for it stopped the whole part until a hand step on the bus. Every startup open in the parts is now essential or optional. Essential ones (a part's own state and the input it exists for) still stop the start, with an error naming the bucket and its grant. Optional ones are said and left: watches the bus refuses too. The builder builds trunk keys without the gate's source, which it opens again at the next candidate that asks a trunk head; toolchains and previews open again at their next event, as a missing bucket did. builder_ask_again says that asking a running step again builds it twice.	2026-10-25 22:29:31 +01:00
jschoubben	d4a054bfed	Assigner: say why a node gets no want, in the journal and in its removed want (issue 1945) ... A new assignment whose trunk build was not done fell through the rules with nothing said: no want, no neither-list entry, no log line, and the rule holding it back was computed and dropped. The pass now logs the rule when a node's reason appears or changes and when it has a want again, one line per change. A node whose want is removed and that does not run the module gets the reason in that removed want's words, so assigner_want answers why; a node with no key gets no removed want, since its node agent would then remove the module and stop holding its resources back.	2026-10-25 22:29:03 +01:00
jschoubben	c623e8d235	Builder: ask again an ask its stream can no longer answer, and give it tools to read and ask again (issue 1945) ... A build ask its seat's stream gave up on, dropped or ended with no step was waited for with no end, and on restart taken over and waited for again: no build node would ever answer it, and nothing could ask it again (trunk key of mesh-build-node at 4e7b118e, building since 19:06; seven keys at 18:44). At the step bound, a context's bound and no timer of its own, the builder reads what the bus says of an ask with no step: gone from its stream, or first in line while a node took a later ask. Such an ask is asked again under a new id the key names, logged and said as build.asked-again, at most three askings, then the key fails with why. The bus's max-deliveries advisory would tell it sooner, but the builder is granted neither it nor the workers' information, and the controller is not changed here. builder_stuck reads every waiting key with its asks, askings and steps; builder_ask_again writes the new reasks state, which the builder watches and answers.	2026-10-25 22:29:03 +01:00