Phoenix Websocket Error/Exception Handling

chanon

I am using something like this to to handle Websocket requests:

  def handle_in("new_msg", data, socket) do

    # do something with data that might result in exceptions/exits/errors raised

    {:reply, {:ok, output}, socket}
  end

And in JavaScript side, something like this

 channel.push("new_msg", data, 10000)
    .receive("ok", (output) => console.log("created message", output) )
    .receive("error", (reasons) => console.log("create failed", reasons) )
    .receive("timeout", () => console.log("Networking issue...") )

What happens is, when an exception is raised it seems the whole channel process (?) goes down, and the client which is waiting for a response gets no response and just times out.

What I would like instead is to be able to return an error immediately with maybe “unexpected error” reason kind of like a http 500 error.

I don’t want to leave the client hanging and it isn’t a “Networking issue” so timeout isn’t appropriate result.

After some trial and error, I now have the following, which seems to work nicely:

  def handle_in("new_msg", data, socket) do

    try do
        # do something with data that might result in exceptions/exits/errors raised
        {:reply, {:ok, output}, socket}
    catch
        :exit, error ->
            Logger.error(Exception.format_exit(reason))
            {:reply, {:error, %{reason: "Unexpected Error"}}, socket}
    end
  end

But I am a bit unsure, as

I think for http requests Phoenix handles this and automatically responds with 500 code? But for websocket requests I have to handle this myself?
And also the Elixir tutorial seems to say that you wouldn’t normally need to use try/catch
And would I also need a rescue?

EDIT: I am now doing it like this as all my messages need replies:

 # try catch here
 def handle_in(event, params, socket) do
    try do
      {:reply, handle(event, params, socket), socket}
    catch
      :exit, reason ->
        Logger.info("responding with unexpected error")
        Logger.error(Exception.format_exit(reason))
        {:reply, {:error, %{reason: "Unexpected Error."}}, socket}
    end
  end

# handle each message type, no boilerplate
defp handle("new_msg", params, socket) do
  # do stuff
  {:ok, %{result: output}}
end

defp handle("another_msg", params, socket) do
  # do stuff
  {:ok, %{result: output}}
end

4 comments

/phoenix #websockets #exceptions

1 3916 4

2019-06-30 10:14:34 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

lud

Hello,

I have the same problem. I use promises to call into the channel from different parts of my javascrtipt code :

function ppush (channel, event, payload) {
  return new Promise((resolve, reject) => {
    console.log("ppush '%s' payload:", event, payload)
    channel.push(event, payload)
      .receive('ok', resp => {
        console.log('received ok: ', resp)
        resolve(resp)
      })
      .receive('error', resp => {
        console.log('received error: ', resp)
        reject(resp)
      })
  })
}

But I have no idea how to catch exits from the channel. It would be very useful during development process.

Of course we could handle channel.onError but you have to handle all errors, not only from the current push.

Post #1

idi527

You can write a custom phoenix channel which would send an error message to the client on exception and keep working. It would probably be similar to the default channel implementation bot with plug’s error handler try/catch logic like here (I think).

Is it a good idea? ¯\(ツ)/¯

Post #2

lud

I’d rather stick with a JS only solution as the default channel implementation is great but I believe it is not possible because of how websockets work : you can send multiple messages from the browser in a timespan an not be able to known wich one caused the server channel process to exit.

A satisfying solution would be to .receive('error', fn) when the socket is disconnected while doing a push instead of only receiving a timeout, something like that:

const errDispatcher = new EventEmitterFromSomeLib()

socket.onError(err => errDispatcher.emit('error', err))

function ppush(channel, event, payload) {
  return new Promise(function (resolve, reject){
    let unsubscribe
    function rejectUnsub(err) {
      unsubscribe()
      reject(err)
    }
    unsubscribe = errDispatcher.subscribe('error', rejectUnsub)
    channel.push(event, payload)
      .receive('ok', data => {unsubscribe(); resolve(data)})
      .receive('error', rejectUnsub)
      .receive('timeout', rejectUnsub)
  })
}

But I do not know if socket.onError does always mean that it’s disconnected or if a push could resolve anyway. Maybe a check to isConnected would be necessary with something like maybeRejectUnsubIfDisconnected along with rejectUnsub.

Post #3

idi527

I think there is also channel.onError which is supposed to handle channel process dying and socket disconnecting. I’d guess socket.onError only handles the latter.

Post #4

— All posts loaded —