48 lines
2.6 KiB
Markdown
48 lines
2.6 KiB
Markdown
---
|
|
status: located
|
|
opened: 2026-09-30
|
|
located-in: [mesh-controller internal/catalogue/settings.go (settle), mesh-controller internal/catalogue/declaration.go (composed, ownNames)]
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 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](../../02-DECISIONS/0155-a-definition-names-no-installation-and-how-that-is-checked.md)),
|
|
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](../../02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md) 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.
|