a month ago
Single Postgres service in our project (Postgres, service ID 803f791d-5765-4cc0-8e8f-7ecc426de344, project protective-smile / e6adffd3-6dba-4ec8-baf9-0ebb4be6bd8d). The TCP proxy URL (yamanote.proxy.rlwy.net:11720) routes to a DIFFERENT Postgres pod than the internal URL (postgres.railway.internal:5432).
Both URLs use identical credentials and reference database railway. The webhook handler in our backend service (discoverymailbox-backend, 8da3a73e-a0c0-4a0a-8309-817927dcd081) writes via the internal URL and the rows land correctly (verified via railway connect Postgres and the Database tab in the Railway dashboard: ~12 shipment_state rows, ~150+ webhook_events). But local connections via the TCP proxy URL see a much smaller, divergent set of rows that look like a stale sandbox DB snapshot.
Regenerating the TCP proxy (deleted yamabiko.proxy.rlwy.net:10353, generated yamanote.proxy.rlwy.net:11720) did not resolve — the new proxy still routes to the same stale pod.
Suspect there's an orphan Postgres pod from an earlier migration/restore that the public proxy keeps routing to. Can you re-point the TCP proxy at the active pod (or surface and clean up the orphan)?
1 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
Status changed to Open mykal • about 1 month ago
a month ago
Resolved on our end. The issue wasn't Railway routing. Our local operator scripts were reading a stale DATABASE_URL from a project .env file (Bun auto-loads it) instead of the intended database, which made it look like the public TCP proxy was serving different data than the internal URL. Thank you.
Status changed to Solved heyimhowie • about 1 month ago