a month ago
Workspace: Sage Lewis's Projects (PRO plan)
Project: Content SageRock → Service: content-platform (production)
Also affected: my mail service (separate Express app, same account)
Symptom:
GET requests are 100% fast. POST/PATCH requests (anything with a body) intermittently hang for 30s–200s+ and then return 502, while the container sits idle (CPU/memory
≈ 0). Reproducible with a single isolated curl — not load-related. Roughly 1 in 2–3 body requests fail.
Container logs during the hangs:
BadRequestError: request aborted
at IncomingMessage.onAborted (/app/api/node_modules/raw-body/index.js:245:10)
at abortIncoming (node:_http_server:796:9)
at socketOnClose (node:_http_server:790:3)This is express.json() (raw-body) reporting the request body was severed mid-stream — i.e. the body never fully arrives at the container.
Edge HTTP log example:
PATCH /api/admin/posts/… → 502 after 208,360 ms
Already ruled out on my side:
- App logic — a second, unrelated Express service shows identical behavior; a different SPA service (doesn't read the body) is unaffected.
- Database — direct writes are instant.
- Container health — idle (≈0% CPU/RAM) during the hang.
- keepAliveTimeout/headersTimeout raised to 75s/76s — no change.
- HTTP/1.1 vs HTTP/2 — both hang.
- Custom-domain/wildcard config, container restarts, fresh deploys — no change.
- App binds to all interfaces on the injected PORT; GETs prove the port/host are correct.
Question: What is causing request bodies to be aborted between the edge proxy and the container for these services? Is this a known edge/region issue, and what can I do
to restore reliable body delivery?
7 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
---Update — additional data: The requests are actually succeeding server-side; they're just extremely slow. When a "hung" POST/PATCH is left alone, the database row
does get written — I've confirmed multiple records landed despite the browser receiving no response for 30s to several minutes. So this looks less like the request body
being permanently dropped and more like severe latency delivering the request body and/or returning the response between the edge and the container: the write
completes, but the client frequently never receives the response (or gets it only after a 502). GET requests remain consistently fast — only body-bearing requests are
affected.
a month ago
That ties back to application-level inefficiencies. We aren't seeing anything on our end that would cause this.
Status changed to Awaiting User Response Railway • about 1 month ago
jake
That ties back to application-level inefficiencies. We aren't seeing anything on our end that would cause this.
a month ago
Chiming in to corroborate this—we are experiencing the exact same issue on our production backend service.
A support agent suggested this might be due to "application-level inefficiencies" or event loop blocks, but our telemetry (and us seeing the same issue in a separate application) strongly refutes that. We added detailed request-lifecycle and event-loop logging at the Express boundary, and here is what we are seeing:
TCP Connection opens, but body is stalled: Our server logs the request headers immediately (graphql.request.received), but the request stream never emits a data event (bodyBytes = 0) or an end event for the slow requests. The socket is open, but the edge proxy isn't sending the payload.
Node Event Loop is Idle: We are tracking event loop delays via perf_hooks.monitorEventLoopDelay(). During the hangs, the mean delay is 1-5ms and p99 is <75ms. The application thread is completely free and responsive.
Bypassing the Proxy is Instant: Curling the exact same POST body payload locally inside the container (using 127.0.0.1:[PORT]) executes in 2 milliseconds. If there were an application-level inefficiency in our middlewares or body parser, the local curl would also hang.
Bypasses DB/APIs: We reproduced this on a static __typename query (125-byte payload) that completely bypasses database queries, session lookups, and third-party APIs.
This is a delivery-level problem between the edge proxy and the container, not an application-level issue.
I can DM our specific Project and Service IDs to a Railway staff member to help investigate.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Deepest apologies I think this was related to an edge network issue we saw yesterday. Is it resolved now? We can also escalate it
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
Chiming in to corroborate this as well, we saw the same class of issue yesterday on our production backend.
In our case, POST /graphql requests intermittently took 50s–200s+ while the application had already received the request headers, but was still waiting for the request body to complete. Once the body was fully received, GraphQL execution completed in milliseconds.
This affected our production custom domain, and appears to be resolved this morning without any action from our side.
We also initially received the same “application-level inefficiencies” response, despite the request lifecycle logs pointing to the body being stalled before reaching the application layer.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Yeah, I woke up yesterday and it was working fine, and it's working fine today. Thank you very much.
a month ago
Apologies for the earlier response attributing this to application-level inefficiencies - the evidence you and others provided clearly pointed to a platform-side issue. This was caused by a problem at our US West edge location that has since been resolved: https://status.railway.com/incident/4RCTTSB5
Glad to hear things are back to normal.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved dizzydes90 • about 1 month ago