Private networking - webhook error
I'm working on a new callback pattern for realtime GraphQL subscriptions that utilizes a webhook like pattern. I want to use the internal networking in railway to secure that callback url, but I'm getting an error:
I'm currently listing my public url as:
http://{private}.railway.internal:${env.PORT:-4000}/callback
Is there anything jumping out why this wouldn't be working? I already have everything working successfully when I use the public domains avaialble.41 Replies
Project ID:
38b0d466-9168-4f9f-bf7f-c09650f565e8
38b0d466-9168-4f9f-bf7f-c09650f565e8
the private networking interface takes about 100ms to become bound, and another 2-3 seconds for private dns resolution to come online, any internal network requets during this time will very likely fail
Does it mean we need ~3s on pod startup or for each of the network calls?
if they are internal network calls, yes, a 3 second grace period is needed, or auto retries is an option too
railway will be working to shorten or eliminate the need for this pause
Okay I've tried adding some stuff here but I'm still getting errors.
I added some code to wait for the service to be ready:
I hardcoded the port that my other service is in and I'm seeing this error in my other service (project id: 19b30993-43c6-4719-b45a-81d55968ec20):
I figured I should get any positive http response (even
404
is fine) and then it's good to continue my request chainso uh whats with
{private}
is that just you hiding information?I guess?
I mean yes, is it hiding anythhing really?
wdym you guess? lol
is that what your code actually has written in it?
I have this
http://hosted-router.railway.internal:7718
okay so what was the point of
{private}
So I didn't put
hosted-router
in discord, but I'll just change that laterare you using nixpacks
Currently only the defaults when I deploy, I see Nixpacks in my settings
actually the service that I'm exposing the internal domain on is docker
the service it's being reached from is using Nixpacks
everything is docker
but the image is built with nixpacks
do you have internal networking enabled
that right?
i assume you are just seeing that json error log indefinably?
yup, still going in the logs
and that code is from a nodejs server
yup
well im stumped
This stuff is hard
its always just worked for me lol
I know that feeling so well 🤣
wanna try awaiting a setTimeout so that it acts as a blocking pause before any network requests are done?
yeah like 3s?
yes, max time ive seen is 3s
average time is 1.5s but 3s is a good safe time
no luck
i dont see a pause in the timestamps?
also, node 20??
🤷♂️ I just say above 18
Sorry I misunderstood and put the sleep before the timestamps, not in them. I'll change that
where did you put the pause?
sleep 3 && npm run start
👆 that's just in my code, it's a web server that is already started up before the request issue
and same issue?
as a last ditch attempt, add
ENABLE_ALPINE_PRIVATE_NETWORKING
set to true
in your service variablesOkay there was some success in that, I get a response error:
This is now something else I need to look into that might not be railway, since this is the Apollo Router receiving a response from a downstream service and that is the actual gql response coming back
one more thing
in the
hosted-router.railway.internal
service variables do you have a fixed PORT set?I do not, I just have hardcoded in the subgraph I'm testing that port hardcoded
everything else listens on the
$PORT
environment variable
(which I don't set)
(but I might need to)since railway assigns it randomly, that means it makes it hard to do an internal request to a service on a random PORT
so yeah might want to set that to a fixed value in the service variables
ya good call, I will do that for sure
I at least have something more to investigate and I'll report back my findings end of day. I'm hoping to trim that code down into a small block I can reference and ideally delete in the future when y'all get to that point ❤️
i really do hope railway is able to make private network initiation instant so theres no need for these hacky work arounds. dont tell them i said this, but i dont think they sould have brought privnets out to public and enabled them by default with this flaw