Hey Kevin,

If the application performance degrades over time depending on the length of the request, then unfortunately, it won't seem to be an issue with Railway. I would make sure that your Dockerfile has all of the required system components.

When you test locally with that Dockerfile, do you observe the issue?

Thanks,
Angelo

Hey Angelo, thanks for your response.

I tried again multiple times and everything worked perfectly:

- locally

- locally with Docker

- on other cloud providers like Scaleway or Gcloud

I'm sorry but I really think there is an issue with Railway. Can you look into that issue? Thank you very much.

Can you provide more information here.

What is producing these error? aka are they showing in your deploy logs for a service?

What is the endpoint you are calling?

Where is that endpoint hosted?

etc, etc.

It seems that the problem only occurs on long queries, usually around ~9 minutes.

I don't have any errors in the console, which is strange because if I look at the logs, I see that the query completes correctly but that's also when the connection is cut and I get this error.

The endpoint is /speech/transcribe.

What do you mean by "Where is that endpoint hosted?"

Right, I'm just trying to understand where you see that error, within your Railway deployment, locally? a web browser, I need more information in that regard.

The endpoint, is that the endpoint of your Railway service or an endpoint of an external API?

9 minutes, what are you querying for 9 minutes? your Railway service or an external API, and where are these queries originating from.

There's just not enough information for us to go off of here.

Hello,

I’ll try to be as detailed as possible.

My POST request is sent from my client (either Postman or a browser) to the Railway public URL given by Railway, calling the endpoint "/speech/transcribe" on my Railway service. This endpoint is hosted on my Railway service and runs on a Nest.js server. The request sends an audio/video URL, and the server processes the media—performing transcription and other analyses—for between 7 and 10 minutes before returning a JSON object with the results. I have noticed that the issue consistently occurs on requests that take longer than 7 minutes.

Here are some additional details:

- Request Details:

- Method: POST

- Endpoint: /speech/transcribe

- Processing Time: Approximately 7 to 10 minutes (with the error typically occurring on requests taking more than 7 minutes).

- Behavior Observed:

- My application logs indicate that the process completes successfully (I even log a success message just before sending the response).

- However, on the client side, I don’t receive the expected JSON object. Instead, I get an error.

- Error Messages in Postman:

- When I set the HTTP version to HTTP/1.x, I receive:

```

Error: 1374391237184:error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT:../../../../src/third_party/boringssl/src/crypto/fipsmodule/cipher/e_aes.c:1065:

```

- When I set the HTTP version to Auto, I get errors like:

- “Error: Stream closed with error code NGHTTP2_INTERNAL_ERROR”

- “Error: Stream error in the HTTP/2 framing layer”

Given that the same Docker configuration works flawlessly locally and on other cloud providers (such as Scaleway and GCloud), I doubt that this is a Docker issue. This leads me to suspect that the problem is network-related—possibly involving TLS/SSL or an internal proxy setup—especially since these errors point to issues during the long-running requests.

Regarding the Dockerfile, I don’t believe sharing the entire file is necessary unless you need specific details about my configuration.

Could you please investigate whether there might be any timeouts, TLS/SSL, or proxy-related limitations on Railway that could be causing these errors on long POST requests? I’m happy to provide any additional information if needed.

Thank you.

Hello,

Your insomnia screenshot shows the request was closed after 5 minutes, and that is indeed our request time limit, the SSL error is just a side effect and can be ignored.

This time limit is not something we will be increasing, instead, we recommend you put in place a polling method to periodically check for updates to the task instead of holding a request open for the duration of the task.

Best,
Brody