2 months ago
Outbound WebSocket (Slack Socket Mode) — handshake succeeds, data frames never arrive
Our listener service (Python, slack-bolt SDK) opens an outbound WebSocket to wss://wss-primary.slack.com. The HTTP upgrade succeeds and the SDK reports "connected", but zero data frames are ever delivered to the container.
- Same code + tokens work instantly on a local machine
- Pattern is identical across 15+ deployments over 18 hours
- Events arrived on 3 sporadic occasions, proving subscriptions are correct
- HTTP works perfectly on the same project (web service handles requests fine)
- Tried multiple reconnect strategies, PYTHONUNBUFFERED=1, etc. -- no difference
- Service has no exposed HTTP port (it's a worker, not a web service)
Is there an egress proxy or idle-timeout policy that could be dropping WebSocket frames on outbound connections from worker services?
Project: DA_Dashboard | Environment: dev | Service: listener | Region: us-east4
1 Replies
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
Hi Enrico, this is a known pattern on Railway. Worker services with no exposed HTTP port can have their outbound WebSocket connections silently dropped or frozen because Railway's health monitoring expects at least one listening port.
When no port is detected, the platform may treat the container as idle or apply aggressive connection recycling.
The fix is simple: expose a dummy HTTP port (even a basic health endpoint on something like port 3000) and set it as the service's port in Railway settings. This signals to Railway that the service is alive and prevents the egress path from being disrupted. Your Slack socket connection should start receiving frames normally after that. A one-liner Flask or http.server endpoint returning 200 is enough.
Let me know if that doesn't resolve it.