3
votes

I've had a lot of fun playing around with the still-beta Phoenix LiveView library. One thing that I'm confused about is how to ensure that my LiveViews will behave in a predictable and transparent way when an exception occurs.

In a conventional HTTP-request-based world, I'd expect that particular request to crash, returning a 500 response and possibly some error page that indicates to the user "Hey, there's a problem with the server". And the developer can count on integrations such as Rollbax detecting and reporting on the exception, so I get an email about the error and can inspect it in the Rollbar dashboard.

But when my LiveView code crashes, I don't get this assurance. The LiveView process will recover from the crash and (as I understand it) revert to its last known healthy state, which is really cool but also could invite user frustration (e.g. "Every time I submit your form, it shows me a loading icon then reverts to the blank form"). And I'm unclear how I could detect or catch exceptions in my LiveView so that they can be reported to an error monitoring service like Rollbar. (Short of impractical solutions like adding a rescue to every handler)

How can I detect exceptions that happen in a LiveView so that I can a) somehow alert the end user of the problem, and b) ensure the exception is reported to the developer?

2

2 Answers

3
votes

But when my LiveView code crashes, I don't get this assurance. The LiveView process will recover from the crash and (as I understand it) revert to its last known healthy state

The way LiveView handles recovery is by having the clent start a new LiveView process. So in case of errors, the current LiveView process will actually crash, which will send a message to Elixir's Logger, which is most likely intercepted by Rollbax (I assume it has Logger integration). So everything should work when it comes to error handling.

How can I detect exceptions that happen in a LiveView so that I can a) somehow alert the end user of the problem, and b) ensure the exception is reported to the developer?

The plan is that an error on connected mount will refresh the page, forcing the request to go through the regular HTTP-connected request which will then raise like it does outside of LiveView. An error on any other handler will cause a reconnection, which will then trigger a connected mount (which then may also fail and fallback to HTTP). But in all of those cases, there is a process, so the errors should be arriving to Rollbax.

2
votes

One might override mount/2 callback. From Phoenix LiveView docs:

If at any point during the stateful life-cycle a crash is encountered, or the client connection drops, the client gracefully reconnects to the server, passing its signed session back to mount/2.
https://github.com/phoenixframework/phoenix_live_view/blob/master/lib/phoenix_live_view.ex#L150-L153

That said, if you expect your LiveView process to become zombie for some reason, you might e. g. maintain the list of connected sockets alongside with timestamps and alarm if reconnects happen in not expected way.