Read_only problem with HTTP client

Questions / Help
,
1

Hi,

I’ve developed a Phoenix application that functions as a REST to SOAP converter. Instead of using a SOAP client package, I’ve implemented it using pure HTTP.

The application receives a JSON message from the client approximately every two seconds, converts it to XML, and forwards it to a SOAP server (SAP).

I’m utilizing Req, which in turn utilizes Finch and Mint.

After successfully sending several hundred messages, I encounter the following errors:

%Finch.Error{reason: :read_only}

03:43:47.343 [error] #PID<0.3996.0> running ErpInterfaceWeb.Endpoint (connection #PID<0.3995.0>, stream id 1) terminated

Restarting my app, which is hosted on Fly.io, resolves the issue.

I’m unsure if there’s a problem with my application, if the external server is blocking me, or if there’s an issue with Finch.

I’ve researched the “read_only” error but haven’t found any useful information. I’m uncertain whether this signifies a problem within my app or with the external server.

I’m considering replacing Req with Tesla, hoping it might resolve the issue.

Any insights would be greatly appreciated.

Regards,
Hector Sansores

1 Like
2

According to a quick GitHub search, “the connection is closed for writing”. :thinking:

This file (the first of two matches in the GitHub search) has 26 matches of read_only, I’d go read it in more detail. (Some of the matches are actually in the symbols outline on the right but still, at least 15 matches in the file from what I’ve seen.)

And this file (the second match) implies that the server “has sent GOAWAY and then replies, we get the replies but are closed for writing” which might be I don’t know, rate limit hit? Or maybe you have inadvertently opened it in HTTP2 streaming mode without the option to write to the connection (as one of the code matches implies)?

3

Sounds like what would happen if you were using a connection kept open with HTTP Keepalive and the remote end decided to close anyways.

For instance, if the remote service wants to deploy a new version of their code they’d likely “drain” persistent connections to the old servers.

I wouldn’t expect that kind of thing to require a reboot though - something should be supervising the connections and reconnect them afterwards. :thinking: