contributes: a module's grant carries no value where it contributed several times #57

2026-09-24T16:55:32Z

jschoubben commented

2026-09-24 16:55:32 +00:00

ContributionsFrom (the function grantsFor uses to settle the single pair credential a requiring module is granted) took the first match from a module's contributions and returned it — correct when a module contributes once, wrong now that ContributesMany (#55) lets it contribute several times under one requirement.

Confirmed live against novox: minio requires route and contributes it twice (files-api, files). The resolved file route-adapter receives showed minio three times — files-api once with a minted credential (from the arbitrary first-match pick), files-api again without one (from contributions()'s own, correct rendering), and files without one. Every single-contribution module (gitea, keycloak, umami) already mints an unused credential for route too — route never needs one, by its own documentation, twice-repeated in this file — but with only one contribution to match, there was nothing to collide with, so it never surfaced.

Fix: where a module has more than one contribution to a requirement, there is no single value to settle on — a pair credential isn't a place to put a label or a port anyway. The module still asks, still gets its one (unused, same as every other route consumer) credential; each named contribution still reaches the provider on its own via contributions(), unchanged.

No cleanup needed for the secret already minted live for minio+route — confirmed by reading secrets.MakeWithOperator: the sealed blob is a random pair credential, unrelated to Values, which is recomputed fresh on every plan/push regardless.

Verified: two new tests (ContributionsFrom with several contributions → empty values, still asks; ordinary single contribution → unchanged behavior), full suite passes except the same two pre-existing failures already on main (confirmed identical with/without this change — gitea SSH port, resolver machines file, both unrelated). Built clean against novox's live mesh-controller. Not pushed — that restarts the live control plane and needs sign-off, same as #55/#56 tonight.

`ContributionsFrom` (the function `grantsFor` uses to settle the single pair credential a requiring module is granted) took the first match from a module's contributions and returned it — correct when a module contributes once, wrong now that `ContributesMany` (#55) lets it contribute several times under one requirement. Confirmed live against novox: minio requires `route` and contributes it twice (`files-api`, `files`). The resolved file `route-adapter` receives showed minio **three times** — `files-api` once with a minted credential (from the arbitrary first-match pick), `files-api` again without one (from `contributions()`'s own, correct rendering), and `files` without one. Every single-contribution module (gitea, keycloak, umami) already mints an unused credential for `route` too — route never needs one, by its own documentation, twice-repeated in this file — but with only one contribution to match, there was nothing to collide with, so it never surfaced. Fix: where a module has more than one contribution to a requirement, there is no single value to settle on — a pair credential isn't a place to put a label or a port anyway. The module still asks, still gets its one (unused, same as every other route consumer) credential; each named contribution still reaches the provider on its own via `contributions()`, unchanged. No cleanup needed for the secret already minted live for minio+route — confirmed by reading `secrets.MakeWithOperator`: the sealed blob is a random pair credential, unrelated to `Values`, which is recomputed fresh on every `plan`/`push` regardless. Verified: two new tests (`ContributionsFrom` with several contributions → empty values, still asks; ordinary single contribution → unchanged behavior), full suite passes except the same two pre-existing failures already on `main` (confirmed identical with/without this change — gitea SSH port, resolver machines file, both unrelated). Built clean against novox's live mesh-controller. Not pushed — that restarts the live control plane and needs sign-off, same as #55/#56 tonight.

jschoubben added 1 commit 2026-09-24 16:55:32 +00:00

contributes: a module's grant carries no value where it contributed several times 8fa5443862

ContributionsFrom settled to whichever of a module's several contributions to
one requirement sorted first, arbitrarily — the grant minted for it then
carried that contribution's label and port under a credential the OTHER
contribution's consumer never sees, and collided with that same
contribution's own entry from contributions() besides.

Confirmed live: minio's two route contributions (files-api, files) produced
three entries in route-adapter's received file — files-api twice, once
credentialed and once not, files not credentialed at all. Every
single-contribution module (gitea, keycloak, umami) already mints an unused
credential for `route` too — route never needs one, by its own
documentation — but with exactly one contribution to match there was nothing
to collide with, so it never surfaced.

Where a module contributes more than once, there is no single value to
settle on. The module still asks, still gets its one credential — a pair
credential is not a place for a label or a port anyway — and each named
contribution reaches the provider on its own, unchanged.

No cleanup needed for the secret already minted live for minio+route: the
sealed blob is a random pair credential unrelated to Values, which is
recomputed fresh on every plan/push regardless.

jschoubben merged commit 856fabda04 into main

2026-09-24 17:39:55 +00:00

jschoubben deleted branch fix/several-contributions-collide-in-grants-v2

2026-09-24 17:39:55 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#57