Case to use or not use :infinity as timeout for calls

Indeed, in recent Elixir/Erlang versions, setting the GenServer call timeout to :infinity is a good default in my opinion: it is generally safe, does not depend on arbitrary timeouts, does not require special handling of messages that come late if the caller rescues failures, and can provide a back pressure mechanism in some cases. If the GenServer crashes, the caller will be notified, so it won’t be hanging forever. One case when it would hang though, is if your GenServer handles the call with a {:noreply, state} and then never sends a reply for whatever reason.

As for Ecto.Repo, I am personally not sure about the implication of the timeout.

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.

It makes sense.

I know what you mean, but at the same time, you are referring IMO to a specific situation, for that case you can consider a lower timeout because you want it to not lock something for too much time.

The point is that for the majority of the calls you would do, this would not be the case, and for that cases, it doesn’t seem to me that it makes sense to use anything but :infinity with the guarantees that @lucaong enumerated.

I needed to use :infinity in my tests because I was expecting a rabbitmq server returns. It works fine, but what @asummers said makes more sense.

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.

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.

That is a very good point that I was not aware of but it makes total sense if you think about it. The caller will be free but the callee would be still “locked/blocked” doing the job the caller requested.

When you say potential deadlock you mean when the caller calls the callee and the calle calls the caller back?

Yeah, I can see that you would get a deadlock forever, but at the same time I don’t see setting the timeout number to something big would help in this case, you would get this GenServer blocked for 3 weeks anyway until the timeout and then probably not too much time later a similar call would come that would block it again to more 3 weeks.

Personally I would consider this specific case as a software bug that needs to be fixed in the code side and not mitigated by timeout parameters.

I would actually say that IME :infinity timeouts have precisely the opposite effect. They obfuscate the problem because operations which can never succeed (in a reasonable time frame or not) do not result in local, actionable errors that can be handled at the calling site, logged, observed, or otherwise raised for human attention. They just result in deadlocks and upstream timeouts where someone else above you in the logical hierarchy chose not to use :infinity, perhaps at your load-balancing layer in the case of a web service.

The only way I can say :infinity helped me do discovery while understanding a problem was by providing a big red flag that I can search the codebase for to find the likely offender, which I assume is not how you meant this.