Files
hq/04-ISSUES/173-a-modules-settings-reach-every-fact-it-contributes/00-report.md
T

2.6 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
located 2026-09-30
mesh-controller internal/catalogue/settings.go (settle)
mesh-controller internal/catalogue/declaration.go (composed
ownNames)

173 — A module's settings reach every fact it contributes, not only the file that asked

What was observed

Setting the mail module's operator values — domain, sitename, website, proxy-address — so that its environment file could read them as ${setting:…} (ADR 0155), and then planning the control node, showed the four keys in places nothing asked for them:

  • in every route the module contributes to the proxy, beside label, endpoint and port;
  • in the database it contributes to the store's provider, beside the database's name;
  • in the smtp facts every consumer of its mail provision is bound to.

Nothing broke: a provider ignores a key it does not read. But a proxy now receives a mail server's proxy-address and website as if they were route facts, a consumer of mail is told the site's name, and a reader of plan cannot tell which of a contribution's keys the module meant and which leaked in.

Why this is here

Settings are one flat map per module, laid over every mergeable file, every contribution and every served fact alike (settle). That was the right generality when a setting was a contribution's override — a route's label is the example the code gives. It stops being right the day a setting is an operator's value for one file, which ADR 0155 made ordinary. The design permits a value to travel where nobody sent it, silently, and every consumer of a provision reads a map that grows with the provider's unrelated settings.

ADR 0112 and design 27 already say where this ends: a requirement has a contract, and a value goes to the requirement that asked for it. Until that form exists, this is the cost of the placeholder being the first case of it.

Open questions

  • Should a key a file asks for with ${setting:<key>} be withheld from contributions and served facts, or should a contribution's overrides live under their own key (contributes, serves)? The second is the shape design 27 draws; the first is the smaller change and keeps the leak from widening while it is drawn.
  • What does a consumer do with a served key it did not expect? Today: nothing, silently. A served map is not checked against what the provision's contract says it carries, because there is no such contract yet.