J0 / phoenix_gen_socket_client

Socket client behaviour for phoenix channels
MIT License
232 stars 48 forks source link

Issue with Serializer #54

Closed vladra closed 3 years ago

vladra commented 3 years ago

Hi ✌️

I have an issue when trying to join a channel, after connection has been established.

Joining is done via GenSocketClient.join(transport, "foo"), which returns {:ok, 1}. But phoenix server that acts as a receiver fails with the following error (sorry for formatting):

[error] Ranch listener GreenHubWeb.Endpoint.HTTP had connection process started with :cowboy_clear:start_link/4 at
#PID<0.4686.0> exit with reason: {:function_clause, [{Phoenix.Socket.V2.JSONSerializer, :decode_binary,
["[1,1,\"foo\",\"phx_join\",{}]"], []}, {Phoenix.Socket, :__in__, 2, [file: 'lib/phoenix/socket.ex', line: 466]},
{Phoenix.Endpoint.Cowboy2Handler, :websocket_handle, 2, [file: 'lib/phoenix/endpoint/cowboy2_handler.ex', line: 175]},
{:cowboy_websocket, :handler_call, 6, [file: '/app/deps/cowboy/src/cowboy_websocket.erl', line: 528]}, {:cowboy_http,
:loop, 1, [file: '/app/deps/cowboy/src/cowboy_http.erl', line: 254]}, {:proc_lib, :init_p_do_apply, 3, [file: 'proc_lib.erl', line: 226]}]}

As a result channel join silently fails (btw not sure if it's expected, since my handle join error handler is not being called).

Looks like the issue is within Phoenix.Socket.V2.JSONSerializer.decode_binary, which tries to decode "[1,1,\"foo\",\"phx_join\",{}]".

It treats "[1,1,\"foo\",\"phx_join\",{}]" argument as binary, because it is intentionally done so in gen socket client serializer

But related to the source code of phoenix v2 protocol, binary format is very different, and actually text format was used in gen socket client. So "[1,1,\"foo\",\"phx_join\",{}]" perfectly matches to text decode fn (Phoenix.Socket.V2.JSONSerializer.decode_text)

Locally, by forcing gen socket client to use text format instead of binary solved my issue. Can you suggest please if this is a bug, or am I misusing library in some way? Thanks in advance


Updated:

Probably it's a bug with Phoenix 1.5, cause previous version of phoenix (1.4) used only one way to decode message

lukaszsamson commented 3 years ago

I stumbled on the same error after upgrading phoenix from 1.5.4 to 1.5.7. 1.5.6 is the last working version.

edongashi commented 3 years ago

Thanks @vladra @lukaszsamson. 3.2.1 has been published.