Sometimes an :unknown message is returned when using the mint adapter

[flaviogrossi]

This is a follow up to issue #357, which is still reproducible because the mode option is never set to passive here because put_new will not overwrite the existing value, which is active as set here

Reading the various discussions it seems that it was meant to be default, so i think the right way is to set it in the @default attribute instead.

I opened a PR #812 which should fix the problem (marked as draft because a review is needed for the reasons outlined there)

[flaviogrossi]

some more details: when using active mode (the default without the proposed PR), what happens is that the mint adapter will hit this condition

trying to debug, it seems to happen because this clause won't match because the socket in the first argument is different from the socket in the second argument tuple

For example, printing both arguments when the condition is met with something like

def stream(%__MODULE__{socket: socket}, message) do
    IO.inspect(socket)
    IO.inspect(message)
    :unknown
end

i got

first argument's socket: {:sslsocket, {:gen_tcp, #Port<0.81>, :tls_connection, :undefined}, [#PID<0.1318.0>, #PID<0.1317.0>]}
second argument: {:ssl_closed, {:sslsocket, {:gen_tcp, #Port<0.80>, :tls_connection, :undefined}, [#PID<0.1314.0>, #PID<0.1313.0>]}}

and ultimately the client request fails with {:error, :unknown}

With passive mode, everything is working fine

I wil add more details as soon as i find something else which may be of help

[yordis]

That sounds proper what you expect here. Thank you so much for helping!

[flaviogrossi]

That sounds proper what you expect here. Thank you so much for helping!

Maybe i'm missing something, but is it proper? The tesla client ultimately returns {:error, :undefined} instead of the http response even though the server request was successful and the data on the wire correct. Also, the same exact request will never fail if using passive mode in the adapter

I'm not an expert on the tesla or mint internals, but shouldn't the pids (or the port) in the socket be the same for both arguments in the same stream invocation? if they were, the handle_close would be called instead of producing the :unknown error. Please note that in my reproducible case there are multiple parallel http requests to different web servers

Thanks for your help on the issue

[flaviogrossi]

some more details:

adding a log here with the text "opened socket to #{inspect url} is #{inspect conn.socket}"

and here like "message #{inspect message} is received from socket #{inspect socket}"

what i get is

"opened socket to \"https://172.23.42.250\" is {:sslsocket, {:gen_tcp, #Port<0.72>, :tls_connection, :undefined}, [#PID<0.1273.0>, #PID<0.1272.0>]}"
"opened socket to \"https://172.23.42.3\" is {:sslsocket, {:gen_tcp, #Port<0.73>, :tls_connection, :undefined}, [#PID<0.1278.0>, #PID<0.1277.0>]}"
"message {:ssl_closed, {:sslsocket, {:gen_tcp, #Port<0.72>, :tls_connection, :undefined}, [#PID<0.1273.0>, #PID<0.1272.0>]}} is received from socket {:sslsocket, {:gen_tcp, #Port<0.73>, :tls_connection, :undefined}, [#PID<0.1278.0>, #PID<0.1277.0>]}"

which seems to indicate that there are two opened sockets to two different hosts opened at the same time, and then :ssl_closed from the first connection is received with the second socket as argument, which causes the :ssl_closed message to be discarded and instead :unknown is returned to caller

This only happens with the active mode

Please let me know if there's something else i could do to debug this