mesh-provisioner: never ask to retire access on an incomplete read #599

Merged

mesh-tools merged 4 commits from fix/940-no-retire-on-partial-read into main 2026-11-02 23:26:49 +00:00

Conversation 2 Commits 4 Files Changed 5

+621 -49

4 Commits

Author	SHA1	Message	Date
jschoubben	134baf0e3b	Check again: the previous check failed only on ace's full root disk ... Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL	2026-11-02 23:52:44 +01:00
jschoubben	7c78fd2e0c	mesh-provisioner: say a lasting unpublished hold by time, not by passes (issue 940, review 2) ... A pass runs on every change of its node, and a newly placed module stays unpublished for the minutes its build takes, so counting passes made every new placement unhealthy while nothing was wrong. The health now says a hold only once a module has stayed unpublished at one build for longer than 45 minutes (the build step's bound is 30), with since when; a published module or another build starts the clock again. Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL	2026-11-02 23:22:43 +01:00
jschoubben	9239177efd	mesh-provisioner: an unpublished composition holds only its own module (issue 940, review 1) ... A node-wide hold while any module's composition was unpublished meant one placed module whose newest build never completes blocked every retirement on its node for good, said only as a line of the pass. The incomplete first read is already covered by the load gate, and an unpublished module's own plan and keys are already kept as held. So the node-wide hold goes; a removed consumer retires beside an unpublished module, and a module held unpublished for more than two passes in a row is said on provisioner_health with its build. Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL	2026-11-02 23:21:20 +01:00
jschoubben	a1d98c2438	mesh-provisioner: judge no retirement from a partial picture (issue 940) ... At 2026-11-02 22:55:58 the provisioner's first pass after a new membership read part of the picture, took the modules missing from it as handing nothing, set 21 route keys of running web apps retiring and asked the operator to remove them; 3 s later the next pass put every plan back. Only 3 asks reached the router; the other 18 were refused yet counted asked. Third of its kind (937, 1332), so the kind is fixed, not the instance. Quick fix: wait for the watched reads' first load before any pass. Thorough fix, chosen because the kind recurred three times and its obvious answer would cut running apps off their routes: - no pass judges before placement, wants, haves, the indexer's modules and the published compositions have loaded once; a read error fails the pass instead of reading as empty; - while a module's composition is not published at its build, no key on that node turns retiring and no plan is removed; a placed module with no known build is held, not counted as handing nothing; - a key whose consumer still has a want or a have on the node and no plan read in this pass is left as it is; - a pass that would retire most of a node's consumers at once (more than 3, or more than half and at least 2) retires and asks nothing and says it as a fault through provisioner_health (runtime-health, so a condition names the likely cause); provisioner_compose retire-many is the operator's word that such a removal is meant; - at most 3 asks stand open (the router's bound per asker); the rest wait and are raised as one ends, and an ask the router holds no record of a minute on is raised again. Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL	2026-11-02 23:17:07 +01:00