fix: postgres consumers connect to the mesh-named db (the login), not a hardcoded name #13

2026-09-06T11:47:28Z

jschoubben commented

2026-09-06 11:47:28 +00:00

The postgres provisioner creates each consumer a database named after the login the mesh minted (mesh_<node>_<module>) — ADR 0048, "a same-named database under exactly that login." But six consumers hardcoded their app db name (DATABASE_NAME=baserow, /letta, /umami, NAME=gitea, /keycloak, POSTGRES_DB=nextcloud), so the service connected to a database that doesn't exist (database "letta" does not exist). Each now uses ${bound:postgres-database:as} as the db name — the login, which is also the db name — matching the working meshboard pattern and the provisioner's behavior.

Found by the two-node DB-consumer lab install (assigned-two-node-db); baserow is proven connecting and running there. (The S3 bucket name is the same class of assumption — a separate follow-up, since S3 identity carries its own length bound.)

https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

The postgres provisioner creates each consumer a database named after the **login** the mesh minted (`mesh_<node>_<module>`) — ADR 0048, "a same-named database under exactly that login." But six consumers hardcoded their app db name (`DATABASE_NAME=baserow`, `/letta`, `/umami`, `NAME=gitea`, `/keycloak`, `POSTGRES_DB=nextcloud`), so the service connected to a database that doesn't exist (`database "letta" does not exist`). Each now uses `${bound:postgres-database:as}` as the db name — the login, which is also the db name — matching the working meshboard pattern and the provisioner's behavior. Found by the two-node DB-consumer lab install (`assigned-two-node-db`); baserow is proven connecting and running there. (The S3 bucket name is the same class of assumption — a separate follow-up, since S3 identity carries its own length bound.) https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

jschoubben added 1 commit 2026-09-06 11:47:28 +00:00

fix: postgres consumers connect to the db the mesh named (the login), not a hardcoded app name d301e05794

The postgres provisioner creates each consumer a database named after the login the mesh
minted (mesh_<node>_<module>), per ADR 0048 -- 'a same-named database under exactly that
login'. But baserow, letta, umami, gitea, keycloak and nextcloud each hardcoded their app db
name (DATABASE_NAME=baserow, /letta, /umami, NAME=gitea, /keycloak, POSTGRES_DB=nextcloud),
so the service connected to a database that does not exist ('database letta does not exist').
Each now uses ${bound:postgres-database:as} as the db name -- the login, which is also the db
name -- matching the working meshboard pattern and the provisioner's actual behaviour.

Found by the two-node DB-consumer lab install (mesh-lab assigned-two-node-db); baserow is
proven connecting and running there. The S3 bucket name is the same class of assumption and is
a separate follow-up (s3 identity has its own length bound).

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

jschoubben merged commit 9dbbfbb5b4 into main

2026-09-06 11:47:34 +00:00

jschoubben deleted branch fix/consumer-db-name

2026-09-06 11:47:34 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#13