The thing is, speaking about asynchronous calls in general and not referring to GenServer, it makes sense to explicitly timeout when something takes more than reasonable. With GenServer though, if the call times out, the caller fails, but the server is still running and trying to produce the result even after the timeout. In other words, the deadlock would still be there, as the GenServer would be still blocked. If one really wants to free up resources when an operation takes too long, a custom timeout logic on the GenServer side is better than a timeout on the caller.

Conversely, using a timeout of :infinity would at least ensure that if there is an unreasonable delay, it surfaces immediately. The right action to take is then to enforce a timeout logic that cleans up resources, which is not what the GenServer.call/3 timeout does.

The GenServer timeout was absolutely necessary back when gen_server could crash without the caller knowing about that. Nowadays it’s generally not the case anymore.

IMO :infinity an an antipattern. It could be easily replaced with 3 hours and have the same effect. Should this run for 3h? Probably not. So why say it can run for infinity? If I have an Ecto query that has to e.g. take a whole table lock, and it can’t get the lock (say for TRUNCATE), giving it an infinity timeout will cause it to hold a DB worker forever. Get enough of these and you have major resource contention on your DB.

If I have a single GenServer there’s only one message queue, so it exhibits the same resource contention as a DB. You can model this differently, of course, but naively using :infinity everywhere has the potential to deadlock your whole app. There are cases where you do need :infinity but I can’t think of any off the top of my head where saying 3 weeks or some equally silly large number would be less appropriate.

Well, I understand that timeouts in general are a good thing, but the GenServer.call timeout gives you no chance of cleaning up, and hides the real problem.

Suppose we are in a scenario in which the GenServer operation is very slow. For the sake of the argument, let’s say it hangs forever. If the caller enforces a timeout with GenServer.call/3, even after the timeout elapses the GenServer is still hanging. Any subsequent call will be queued in the mailbox of the hanging GenServer, which keeps growing unbound. The real problem is not solved, because the GenServer is not released.

Using a timeout of :infinity would block the caller forever. It is also not a great course of action, but it reflects the real performance of the GenServer, propagating backpressure at least on that specific caller. I agree that it’s not the solution, but my point is that setting a timeout is not a solution either.

The real solution in such a case is a use-case specific timeout logic inside the GenServer, that knows how to cleanup resources.

Here is a code example of what I mean. Let’s simulate a slow call (also printing a message every second while waiting):

defmodule Slow do
  def call(seconds) do
    for i <- (1..seconds) do
      IO.puts("Waiting #{i}...")
      Process.sleep(1_000)
    end
  end
end

Now create a GenServer setting a 3 seconds call timeout:

defmodule One do
  def start_link(), do: GenServer.start_link(__MODULE__, [], [])

  def hang(pid, seconds \\ 10),
    do: GenServer.call(pid, {:hang, seconds}, 3000)

  def init(_), do: {:ok, nil}

  def handle_call({:hang, seconds}, _from, state) do
    reply = Slow.call(seconds)
    {:reply, reply, state}
  end
end

If we call One.hang(pid), it will hang until the 3 seconds timeout elapses, then error. As we can see from the printed messages though, the slow operation is still going on, and further calls will just engulf the inbox more and more:

{:ok, pid} = One.start_link()

One.hang()
# Waiting 1...
# Waiting 2...
# Waiting 3...
# ** (exit) exited in: GenServer.call(#PID<0.165.0>, {:hang, 30}, 5000)
#     ** (EXIT) time out
#     (elixir) lib/gen_server.ex:1009: GenServer.call/3
# Waiting 4...
# Waiting 5...

One.hang()
# Waiting 6...
# Waiting 7...
# Waiting 8...
# ** (exit) exited in: GenServer.call(#PID<0.165.0>, {:hang, 30}, 5000)
#     ** (EXIT) time out
#     (elixir) lib/gen_server.ex:1009: GenServer.call/3
# Waiting 9...
# Waiting 10...
# Waiting 1...
# Waiting 2...
# Waiting 3...

The GenServer.call timeout is not really helping, as it only stops the caller, not the callee. What would work is to implement logic on the callee side to stop the slow operation and cleanup if a timeout elapses:

defmodule Two do
  def start_link(), do: GenServer.start_link(__MODULE__, [], [])

  def hang(pid, seconds \\ 10),
    do: GenServer.call(pid, {:hang, seconds}, :infinity)

  def init(_), do: {:ok, nil}

  def handle_call({:hang, seconds}, from, state) do
    task = Task.async(Slow, :call, [seconds])

    case Task.yield(task, 3000) || Task.shutdown(task) do
      {:ok, reply} -> {:reply, reply, state}
      nil -> {:stop, :timeout, state}
    end
  end
end

In this case, the slow call is wrapped in a Task that is terminated when the 3 seconds timeout elapses:

Two.hang(pid)
# Waiting 1...
# Waiting 2...
# Waiting 3...

# 18:57:12.341 [error] GenServer #PID<0.165.0> terminating
# ** (stop) time out
# Last message (from #PID<0.104.0>): {:hang, 30}
# ...
# ** (EXIT from #PID<0.104.0>) shell process exited with reason: time out

No more "Waiting #..." messages are logged, confirming that the slow Task is terminated after the timeout elapses.