2.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| located | 2026-09-23 |
|
095 — A module assigned after genesis has no broker account, and finds out by restarting
What was observed
On the control-node, during the first migration, 2026-09-23.
A module was assigned and taken. Its service came up and served correctly. Its sidecar — the part that speaks on the bus — restarted every few seconds with:
cannot read the broker credential at /run/secrets/broker: SyntaxError: Unexpected token 'V',
"VK-XiWBjPt"... is not valid JSON
The module declares an own-secret named broker, as every module on the bus does. The mesh had
minted it as a random value, the way it mints any own-secret, where the sidecar expects an
account: a url with credentials in it.
The account is a separate, explicit act — module issue <module> --node <machine> — which genesis
performs for the foundation's own modules. Nothing performs it for a module assigned afterwards,
and nothing says it is needed. Running it delivered a real account and the sidecar came up.
Why it matters beyond this instance
Every module with a sidecar will be assigned after genesis, because that is what migrating a service is. The failure is late, and it looks like a code fault in the module rather than a missing step: the service works, and only the half that talks to the mesh crashes.
Two mechanisms share one name here. own-secrets: {broker: …} means give me a place to put my
broker credential, and the minting path treats it as mint me a secret called broker. Nothing
reconciles them.
Open questions
- Should assigning a module that declares a
brokerown-secret issue its account, rather than leaving a minted value that cannot work? - Or should the minting path refuse that name, so the missing act is named at once instead of discovered by a crash loop?
- What else declares an own-secret whose name means something to another part of the mesh?