postgres: the provisioner connects to mesh-store's actual port, not a hardcoded 5432 #52
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-catalog#52
Reference in New Issue
Block a user
Found mid-
keycloakmigration onnovox: the DB grant forkeycloaknever landed.mesh-postgres's logs show it retrying against127.0.0.1:5432and failing — forkeycloak, but also forgitea,umami, andmesh-catalog's existing grants:mesh-storeactually publishes on 6852 — its adopted-in-place HAL port, not the mesh's default.MESH_PROVISION_POSTGRESinmodules/postgres/module.jsonwas a literal string naming5432, not a template — unlikemesh-controller's own manifest, which already gets this right with${seat:mesh-store:5432}for the identical connection.Fixed with the same template. Checked
lavinmqfor the same bug class — it's fine, its management port (127.0.0.1:15672:15672) is fixed by its own module declaration, not inherited from adoption.Not yet verified against a live rebuild+redeploy — that's the next step once this merges.
MESH_PROVISION_POSTGRES was a literal connection string naming port 5432 -- correct only when mesh-store happens to run on the mesh's own default. On novox, mesh-store was adopted in place at HAL's original port (6852), and the provisioner has been retrying-and-failing against 127.0.0.1:5432 ever since, for every consumer including ones that already exist (gitea, umami, mesh-catalog), not just a new grant. Fixed with the same ${seat:mesh-store:5432} template mesh-controller's own manifest already uses for the identical connection. No other module needed this fix checked -- lavinmq's MESH_PROVISION_LAVINMQ already used 127.0.0.1:15672 unconditionally, but the broker's management port is fixed by the module itself (127.0.0.1:15672 in lavinmq/module.json's own ports), not by adoption, so it isn't the same bug.The first commit on this branch embedded ${seat:mesh-store:5432} directly inside MESH_PROVISION_POSTGRES's URL. That placeholder resolves to an empty string whenever mesh-store is on its own default port (novox/hq internal/catalogue/seat_into.go: 'the mesh raised on the catalogue's own ports never gives them a setting at all') -- which produces a malformed connection string (host:/postgres) on exactly the common case, a fresh, non-adopted mesh. It only worked here because novox's mesh-store happens to be adopted at a non-default port. mesh-controller's own manifest already has the right shape for this -- internal/envfile/port.go's NAME / NAME_PORT twin, composed by mesh-controller's Placed(): the base value keeps its own port; a separate _PORT variable carries the override, spliced in only when it says something, and left alone -- not a fault -- when it's an unfilled placeholder (a manifest ahead of the running controller). Reverted the manifest to its original base value, added MESH_PROVISION_POSTGRES_PORT as the twin, and taught client.ts (the only consumer -- both tools/ and provisioner/ import it) the same precedence envfile.Placed uses. Checked: no other file in the module reads MESH_PROVISION_POSTGRES directly.Corrected the approach — the first commit embedded the placeholder directly in the URL, which resolves to empty (and produces a malformed connection string) whenever
mesh-storeis on its own default port, i.e. the common, non-adopted case. Only worked onnovoxby accident, becausemesh-storehere happens to be adopted at a non-default port.Fixed properly using the twin-variable pattern
mesh-controller's own manifest already establishes for this exact problem (internal/envfile/port.go'sNAME/NAME_PORT, composed viaPlaced()): base connection string unchanged, a separateMESH_PROVISION_POSTGRES_PORTcarries the override, andclient.tsonly splices it in when it's actually filled — an empty or unfilled-placeholder value leaves the base string's own port alone, same as the Go side does.