REDIS_PRIVATE_URL Not Correctly Populated in PR Deploys
Hi, I am getting failures in PR deploys because the REDIS_PRIVATE_URL environment variable is not being populated correctly by Railway. I am getting a value like
redis://***:***@:6379: the hostname is completely missing. This understandably chokes the Redis client. Please help to resolve. Thanks!
Project ID: 646e0c5a-07fd-4ade-aaed-c92750d977ae14 Replies
Project ID:
646e0c5a-07fd-4ade-aaed-c92750d977ae@jr - internal domains not rendering in pr environments
The internal domain sometimes takes a second to initialize on environment creation. It looks to be all good in your project now
should we add sleep before the deploy step? it's not just a second for DNS to resolve correct? i believe that one has been documented. but here, it's a second before the env vars are usable.
It is just on the very first deployment of a service. The variables should be available from now on
ah, i see! for PR envs, the first deployment is typically the most important one! so, i guess the advice here going forward could be to add a sleep-before-deploy in the PR env config.
The variables should be available from now onfrom this i take it he fixed it?
Ah yes I see. that should work. In the future Railway will fully initialize the private network for all services before deploying the PR environment
I believe so. The variable was fully working in all the environments in the project
however, it's a recurring problem. it will happen again (not always; there's a little randomness) when future PRs are raised. hence my suggestion that the official guidance could be to add a sleep to the start of all relevant PR build configs.
we used to have this issue when you deployed a template too
jr fixed it then 😉
just so y'all are aware, PR deploys are still intermittently failing (which is extremely annoying). i guess i'll add the
sleep 3!
actually come to think of it, i don't think
sleep 3 will work. this ERR_INVALID_URL is occurring more than 2 minutes after the build starts. which means adding another few seconds of delay won't do a thing.
has this issue been noticed recently? really appreciate any resolution!Hmm I see what you mean. The issue is that at the time of deployment when the variables are resolved, the private network hasn't initialized yet. I will try and get this resolved for you this week
ty ty ty!! seems like a potential resolution on the Railway side is to delay PR deployments for a second or two. i wish it could be accomplished by something like a
sleep 1 in the build command, but it seems that juncture is already too late.