One service is unable to connect to Postgres container, while the other connects fine
Hi, I have two typescript services and a postgres service in a project. One of the typescript services is able to connect to the postgres service totally fine while the second one can't.
24 Replies
Project ID:
c7f62dd5-665b-4f22-9f49-a2a9e9b19231c7f62dd5-665b-4f22-9f49-a2a9e9b19231
can you show me a screenshot of the service variables for the service that can't connect?
they are the same on both services ( i copy pasted from the one that can connect to the one that can't)
you shouldn't copy paste the database variables, please delete that database variable and setup a variable reference like that popup wants you to
okay, set up a variable reference, but still same error
can I see another screenshot, just as a sanity check
'
perfect
side note, your other service should be using a variable reference if it's not already, don't worry about it stopping working, we will get to the bottom of this
so now please show me the error you get
the service isn't using a variable reference right now cause for production i'm planning on moving to neon.tech for my postgres deploy, and use railway for just the services
gotcha
are you utilizing the private network at all?
nope
wanna go ahead and disable it?
disabled
redeploying
let the stuff redeploy and get back to me
ooh looks like disabling private networking fixed it! the service is working!
thank you!
okay so why it works, private networking takes about 2 seconds to fully initialise and this can effect calls to things that are not on the private network, if you did happen to be using private networking then you would have needed to increase the timeout to the connection to postgres, but I don't know how that's handled in prisma? maybe a query parameter on the database url variable
is there a reason my other service worked fine?
cause that also uses prisma
maybe just cause it has an express server and that took the required amount of time before prisma kicked in?
oh i guess prisma would only kick in on the working service when i got an inbound request
which would be long enough time for private networking to have initialize
there are many factors, one of the factors I can comment on would be that private networking initialisation times vary slightly
vs the service that wasn't working, where it's a cron script that calls the db straight away
ah yes if the connection to the database isn't done at app start then initialisation times for the private network wouldn't come into play
so i could've solved with even just a regular promise timeout in the service that wasn't working before the prisma network initialized. cool, good to know! thank you π
awaiting a promise timeout, slapping a
sleep 2 && onto the start command, increasing connection timeout, use pg_isready
many solutions, all which I wish we didn't have to do
this could even effect a connection attempt to neon if the connection is done at app start