Archived
jschoubben
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.