julismz
Hi!
I have some doubts about this documentation:
https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#c:terminate/2
I was trying to catch when / why every exit reason is triggered to understand the possible situations where some socket is disconnected and make some decisions.
From what I’ve read on the documentation there are 5 possible exit statuses:
- :normal
- :shutdown
- {:shutdown, :left}
- {:shutdown, :closed}
- term()
I can’t figure out when :normal or {:shutdown, :left} will be called. Could the documentation be outdated? Probably I’m missing something.
These are some tests I did:
Notice: Just in case, I have trap exit enable on liveview server
Results:
| Action | Reason |
|-------------------------|----------------------|
| push_redirect | :shutdown |
|. redirect | :shutdown |
| kill lv process | :shutdown |
| close tab / browser | {:shutdown, :closed} |
| change URL | {:shutdown, :closed} |
| refresh | {:shutdown, :closed} |
|disconnect socket with JS| {:shutdown, :closed} |
| raise error | term() |
Method used to kill liveview process
Process.whereis(QtixWeb.Endpoint) |> Process.exit(:kill)
I’m not able to get {:shutdown, :left} not :normal
I found this peace of code on liveview project:
def handle_info(%Message{topic: topic, event: "phx_leave"} = msg, %{topic: topic} = state) do
send(state.socket.transport_pid, {:socket_close, self(), {:shutdown, :left}})
reply(state, msg.ref, :ok, %{})
{:stop, {:shutdown, :left}, state}
end
So I think it is something related with the Phoenix.socket, am I right?
On the other hand, I couldn’t find the way to get the :normal reason neither.
Once I have this clear, how possible is it to improve the documentation explaining every case? Is there a standard for keeping the documentation so minimalist?
Thanks!
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
Did you try closing the socket via the API from the JS on the frontend?
Call
exit(:normal)from your code.Yes, exit reasons are a well defined set:
Given LVs run user supplied code any of those could be triggered by the user defined code, so there’s no possibility to limit this set further.
The only thing LV could be doing it document the reasons behind the ones it controls specifically, but then again any user provided code could hijack the same reason and use it under different circumstances.
julismz
I mean in the specific liveview context. I think is good to know when we will get each one, if I would like to know what’s the exit if people close the tab we have to make tests and experiments, that could be explained, I’ve no problem in improve the doc in any case it’s possible.
This seems forced (hijacked as you said), what’s the natural way when I will get this? I can run
exit(:foo)but the:fooexit is not in the documentation. I assume that if:normalis on the documentation there is some organic reason that returns it.Yes, I ran
liveSocket.disconnect();from chrome console and got{:shutdown, :closed}I will add this last test to the table too.
Thanks!
LostKobrakai
User code calling
exit(:normal)is at least one of the expected paths to get this exit reason. Yes you can call exit with any term, but OTP behaviours react in certain ways according to those specific exit reasons listed. Like a supervised process with restart strategy:transientwould only restart on an abnormal (not:normal,:shutdown,{:shutdown, term}) exit reason. And again LV (like any otp behaviour) expect the user provided code to potentially callexit/1, soterminate/2needs to be able to handle all of them (the non-abnormal ones, because abnormal ones don’t callterminate/2).I agree that it would be useful to know what values LV does exit independently from user provided code, but that’s never going to be the full set
terminate/2needs to handle.julismz
is not
terminate/2called if you enabletrapping exiton the process? I intentionally raised an exception on anhandle_event/3and got it asterm()interminate/2, I think…Update: Now I remember, for having this work the liveview lifecycle has to be started, if I raise some error on the
mount/3everything blow up andterminate/2is no called at all, you’re right.Once I had to detect even those cases and used process monitors, but that is another chapter
LostKobrakai
The details are listed here: GenServer — Elixir v1.20.2
But given the many reasons for it not being called I’d stick to non-abnormal exit reasons if the intention is to have it be called (and complete).
julismz
Yes… The only mystery is when or why the
{:shutdown, :left}is triggered… Just in case I will use a wildcard on my pattern-matching and consider it the same as{:shutdown, :closed}, in any case, the shutdown is shutdown. I intend to detect when the exit is voluntary or because of an error to take different actions.If I have some time I will prepare some socket routes and try interacting directly with the socket, maybe that is the way.
MMore
Have you found something on this? I see this one too and I am wondering what the reason is
julismz
No… I never found the answer…
steffend
You’ll get a
{:shutdown, :left}if a user navigates away using a<.link navigate="/page">.julismz
Thanks! I will try that