Thank you both. I went for flat tuples and more verbose code. I guess it’s better to have multiple smaller and simpler handler functions that are clearer and easier to reason about, especially if you look at them a few years later, or come into the project from the outside.

To be fair I wouldn’t even use :enrollment_processed because that implies that it finished successfully. Whatever you opt for IMO the first element of the tuple should be something along the lines of :enrollment_failed and then 2nd element and further should elaborate on why did it fail.

Consider two message shapes:

1. Nested: {:processed, {:ok, item}} and {:processed, {:error, item}}
2. Flat: {:succeeded, item} and {:failed, item}

The “nested” option makes it possible to write a generic handler for “processed”:

def handle_info({:processed, status}, socket) do
   update_status(status)
end

…but leads to extra destructuring if you have two separate handlers:

def handle_info({:processed, {:ok, item}}, socket) do
   set_succeeded(item)
end

def handle_info({:processed, {:error, item}}, socket) do
   set_failed(item)
end

The “flat” option forces you to use two handlers, but they’re more readable and efficient than the two handlers of the “nested” option:

def handle_info({:succeeded, item}, socket) do
   set_succeeded(item)
end

def handle_info({:failed, item}, socket) do
   set_failed(item)
end

So I’d recommend nesting as much as you need for pattern matching, and not more.

Yes, remember, you are communicating mainly to other developers (including yourself many months later). If we were communicating mainly to the machine, we would (still) be writing in binary.