fix(dev): let PGPORT choose the postgres host port - #3854
Closed
ruben-carrera wants to merge 1 commit into
Closed
ruben-carrera wants to merge 1 commit into
ruben-carrera wants to merge 1 commit into
Conversation
Addresses the Postgres half of #2479. docker-compose.yml published postgres on a hardcoded 5432, so local setup breaks whenever something already owns that host port. The failure is worse than a plain bind conflict: a more specific 127.0.0.1:5432 listener wins over the docker forward, so connections reach the *other* Postgres, which then rejects the dev credentials. `just relay` dies at _ensure-migrations with "password authentication failed for user buzz" and no hint that a port conflict is the real cause. Publish the port as ${PGPORT:-5432}, reusing the variable .env already defines rather than introducing a second one, as proposed in #2479. Compose interpolates it from .env automatically. The committed default is unchanged, so CI and existing checkouts keep using 5432. start-relay-for-tests.sh hardcoded the same port in three places and does not source .env, so it would have overridden any override. PGHOST and PGPORT now fall back to the standard defaults instead of being pinned, DATABASE_URL is derived from them rather than spelled out a second time, and the pgschema desired-state planner reuses them too. Redis still needs the equivalent treatment (BUZZ_REDIS_HOST_PORT plus the dev-setup.sh collision check) to close #2479 fully; left out here to keep this change to one service. Signed-off-by: D12Labs <Ruben.Carrera@District12Labs.com>
Contributor
|
useful. please document that existing local volumes keep the old port mapping until recreate, so people dont think pgport alone moves data |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
docker-compose.ymlpublished Postgres on a hardcoded5432:5432, so local setup breaks whenever something already owns that host port.The failure mode is nastier than a plain bind conflict. A more specific
127.0.0.1:5432listener takes precedence over the Docker forward's*:5432, so connections silently reach the other Postgres, which then rejects the dev credentials.just relaydies in_ensure-migrationswith:Nothing points at a port conflict — a real Postgres answered, it just wasn't ours. In my case the squatter was a
cloudflared access tcptunnel; the linked issue hit the same wall with Homebrewpostgresql@15.This publishes the port as
${PGPORT:-5432}, reusing the variable.envalready defines rather than adding a second one, which is the direction proposed in #2479. Compose interpolates it from.envautomatically, so the conflict is resolved without editing tracked files.The committed default is unchanged, so CI and existing checkouts keep using 5432.
scripts/start-relay-for-tests.shhardcoded the same port in three places and does not source.env, so it would have overridden any override.PGHOST/PGPORTnow fall back to the standard defaults instead of being pinned,DATABASE_URLis derived from them instead of being spelled out a second time, and thepgschemadesired-state planner reuses them too.Related issue
Addresses the Postgres half of #2479. That issue also asks for
BUZZ_REDIS_HOST_PORTand a matchingdev-setup.shcollision check for Redis — deliberately left out here to keep this to one service, so #2479 should stay open. I searched open PRs forPOSTGRES_PORT/ postgres port conflicts and found no duplicates.Testing
Verified on macOS with Colima, reproducing the original conflict (
cloudflaredholding127.0.0.1:5432):PGPORT=5442in.env,docker compose configresolvespostgres.ports[0].publishedto5442; with it unset,5432.just relaystarts clean — migrations apply,/healthreturnsok, NIP-11 serves, relay listening onws://localhost:3000.just test— all 9 steps pass, 954 passed / 0 failed.run-tests.shsources.env, so this exercises the remapped port end to end, including the_ensure-migrationsstep that previously failed.just check— clean (fmt, clippy, desktop, tauri, web, mobile lint).bash -n scripts/start-relay-for-tests.sh— clean.Not covered:
scripts/start-relay-for-tests.shis CI-only and I did not execute it, so its three edits are verified by inspection and a syntax check rather than a run. Redis, MinIO, and the other services are untouched.One unrelated pre-existing failure showed up in
just ciatmobile-test—channel_detail_page_test.dart:1053("keeps follow mode off while a tall newest message stays visible"). It reproduces on a clean checkout ofmainat10d5a2641, so it is not from this change, and this diff touches nothing reachable from Flutter.