---
status: located
opened: 2026-09-23
located-in: [mesh-controller cmd/mesh-controller/modules.go]
fixed-by:
amended-design:
---

# 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 `broker` own-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?