One rule for which provisions a module waits for, so the assigner, the plans and the provisioner agree and grafana gets its route (issue 774) #143

Merged
mesh-tools merged 2 commits from fix/one-rule-for-provisions into main 2026-10-30 22:33:49 +00:00
2 Commits
Author SHA1 Message Date
jschoubben 6c5a8ef893 Test that the composition marks a need its provider's helper answers, so the consumer's plan keys it (issue 774)
mesh/delivery merged: source.main moved to novox/mesh-sdk@125bb9177189
mesh/delivery-group group fix/one-rule-for-provisions merged: every member is merged
mesh/check being carried to 6c5a8ef893b4 on 125bb9177189 | from b74e23f973ab | novox/mesh-sdk#143 in group fix/one-rule-for-provisions
The review found answeredByHelper untested: forced false, every test passed. This row fails then.
2026-10-30 22:29:12 +01:00
jschoubben 91aa7b78fc Key provisions by one rule the plan, the seat and the assigner share (issue 774)
The assigner's rule 8 waited for a key for every `requires`, while the plans named only the needs of handed modules:
every new build of grafana, dnsmasq, mesh-knowledge, mesh-mail and the builders waited for a key nobody would make,
and grafana, not handed, had no plan, so no route key and no route on route-proxy.

catalogue.Keyed is the rule (a need a module answers is keyed when its consumer is handed or the provider's helper
answers it), catalogue.Awaited the same rule from manifests for the assigner, and a module not handed now has a plan
for what a helper answers of it. Handed modules' plans are unchanged.

Quick fix: drop the missing-key check from rule 8. Thorough fix (chosen): one rule in mesh-sdk all three parts use,
since the kind (three parts deciding the same set apart) already drifted once and hid failures as waits.
2026-10-30 22:29:12 +01:00