Closed the-mikedavis closed 3 years ago
see the guide from Phoenix.Logger: https://hexdocs.pm/phoenix/Phoenix.Logger.html
[:phoenix, :socket_connected]
- dispatched at the end of a socket connection
%{duration: native_time}
%{endpoint: atom, transport: atom, params: term, connect_info: map, vsn: binary, user_socket: atom, result: :ok | :error, serializer: atom}
[:phoenix, :channel_joined]
- dispatched at the end of a channel join
%{duration: native_time}
%{params: term, socket: Phoenix.Socket.t}
[:phoenix, :channel_handled_in]
- dispatched at the end of a channel handle in
%{duration: native_time}
%{event: binary, params: term, socket: Phoenix.Socket.t}
~there's probably a good argument to make for splitting out (by event type) telemetry for the connection process and telemetry for the client~
see #13
this issue now only pertains to the client's telemetry
this is really probably not as hard as I would imagine off the bat...
socket
(non-assigns area, maybe a new field called :metadata
)
Slipstream.Socket.apply_event/?
function for ChannelConnected and TopicJoinSucceeded eventsawait_*
interfaceSlipstream.Callback.dispatch/?
functionstill some open questions that can be revisited later:
[:phoenix, :channel_joined]
dispatch at the end of the c:Slipstream.handle_joined/3
callback or at the associated TopicJoinClosed/ChannelClosed event?
c:handle_joined/3
is fine
instrumentation with telemetry could be valuable, but I'm not sure what events we would want to emit
what questions would we be trying to answer with telemetry?