How does process treat unhandled messages?

Here’s something you can run locally:

defmodule MyLoop do
  def loop do
    IO.puts "Entering the loop"
    
    receive do
      :msg_b ->
        IO.puts "msg b"
        loop.()
      :msg_c ->
        IO.puts "msg c"
        loop.()
    end
  end
end

pid = spawn(&MyLoop.loop/0)

send(pid, :msg_a)
send(pid, :msg_b)
send(pid, :msg_c)
send(pid, :msg_a)
send(pid, :msg_b)
send(pid, :msg_c)
Process.info(pid, :messages)

My output:

Entering the loop
iex(17)> send(pid, :msg_a)
:msg_a
iex(18)> send(pid, :msg_b)
msg b
Entering the loop
:msg_b
iex(19)> send(pid, :msg_c)
msg c
Entering the loop
:msg_c
iex(20)> send(pid, :msg_a)
:msg_a
iex(21)> send(pid, :msg_b)
msg b
Entering the loop
:msg_b
iex(22)> send(pid, :msg_c)
msg c
:msg_c
Entering the loop
iex(26)> Process.info(pid, :messages) 
{:messages, [:msg_a, :msg_a]}

You can see that msg_a will pile up in the process queue, as @jwarlander mentions

Yes, indeed it will.. The result, if your process doesn’t ever flush out otherwise unhandled messages, is that it may end up sifting through millions of them just to process those that are relevant. This is something that you’ll need to be aware of; either crash on an unexpected message, or (at some point at least) throw it away.

FWIW this behavior is one of the reasons it’s usually preferable to use structured machinery around send + receive, like gen_server and friends - unexpected messages will be converted to crashes.

If you’d like the gory details: The BEAM Book: Understanding the Erlang Runtime System