15 days ago
All other workspaces have the same services deployed in the exact same way, this specific project is having a really hard time with realtime communication for some reason
5 Replies
3f2b7c41-8144-48ba-959c-46b8713ae230 this is the project id, it's not linked to my current account
14 days ago
Hey — got it. If the exact same code works in other Railway projects, then this is usually one of a few things: network path differences, WebSocket/SSE not actually being used, proxy settings, or per-project config (domains/ports/healthchecks/regions) changing behavior.
A couple quick checks so we can narrow it down fast:
What “realtime” is this exactly — WebSockets, SSE, or long-polling?
Is it failing only on custom domain, only on the railway.app domain, or both?
Does it work locally but not on Railway, or does it work on Railway in other projects but not this one (you said yes)?
Any client error like 1006 / 1011 / 502 / 504 / ETIMEDOUT or “connection closed” messages?
If you can paste:
the service type (Node/Go/etc) + library used (Socket.IO, ws, Pusher, Supabase, etc)
a small snippet of the failing logs (server + client)
the URL you’re connecting to (domain only is fine)
…we can quickly confirm whether this is a WebSocket upgrade/proxy issue vs something project-specific.
Also: since the project ID you shared isn’t linked to your current account, I can’t inspect it directly — but with the answers above we can still pin down the cause and fix.
Hey, So i should give more context for this.
The backend that connects to redis and mongo and other services is Node js, for realtime we use Socket IO and it does connect to them correctly using the internal urls of btoh mongo and redis. What i'm seeing for this project is that it's taking longer than it should for events to arrive, this is not because of the collection size or the number of requests being made to this server, both are exceeded by the other projects. On other projects for example i have more events coming in and more requests being made but this service specifically is slow. I did see that it's still using mongo 7 and I'm gonna be updating that to the latest version but i don't believe that to be the reason requests are taking longer than they should for this service. As for logs, i'm not getting any so no client errors, no connection closing or timeouts. this ises a railway.app generated domain for both the backend and front. we also use metal servers and eu instances for all the services.
I hope this does answer a lot of your questions.
i think i may have found the problem, while the collection size is the same the way the items are being indexed in this specific service in way more frequent manner than the rest. I'll try changing that and see if it gets fixed