A too short timeout is more problematic than no timeout because it breaks the application.

Let's say 10 seconds, typical intuitive but bad timeout. This will cause requests to fail for no reason other than users are in Asia or Africa, high latency. This will break the application when it's used or deployed across datacenters because high latency. This will cause requests to fail when the server is a bit busy (couple seconds more to process requests). Worse, it will cause chain reactions under load, creating more retries and even more load, causing other services/servers to timeout too.

Better go for a long timeout. A long timeout doesn't break the application.

> A long timeout doesn't break the application.

I'm pretty sure infinite timeout also breaks the application, in a way people rarely realize that it is because of the timeout. People would rather think it "just didn't work, don't know why" instead of being very clever and realized "it must be low timeouts!!!"

Not all requests are the same and they need to be treated differently. Some requests are rather optional and it's probably better to timeout if they don't respond in a timely manner so not to use up more resources than needed. Other requests, like payments, for instance, you probably want to give the best chance for it to succeed. So, no timeout is likely a good idea. If the actual TCP connection times out or is closed by the server, we can hope it was good enough to realise something didn't go well and rollback. So, we are probably safer to assume it didn't go through in that case.

When it comes down to UI there are even more options. Since you have a human on the other side, you can transfer to them the responsability of deciding when to timeout. The UI certainly shouldn't become completely unresponsive while a request is being made.

Yes, go ahead and set a 10 minutes rather than infinite or 10 seconds. That will make it much easier to realize that things are frozen because they will raise exceptions and logs all over the place.

To be pedantic though, infinite timeouts don't break applications except some rare cases of resources exhaustion. If an application is completely unresponsive, it is dead for good, not because of the timeout, need to fix the root cause (often resource exhaustion like swapping or it's waiting on another IO or service that's frozen).

Failing because of a too short timeout feels silly, but a stupidly large timeout leads to frustration and hazardous user actions like killing the app with the task manager.

You don't need a timeout, you need a "cancel" button.

Funny you mention that, this reminds me of Windows task management. Windows automatically gives a popup to terminate an application when it detects an application is unresponsive.

This happens regularly when I open large files in some app, they take a fair bit of time to load, Windows offers a popup to kill the app after few seconds. Have to carefully wait and not click anything.

Or a retry button. The point is that the application does not know if your network has a ridiculous latency that messes up tight timeouts

> For waze’s case, I supposed their priority is not on salvaging the 1% longest request (though critical to you), and instead preserve server resources for the 99% faster clients.

What resources? Buffering a response takes a minuscule amount, and if even a tiny fraction of people try again it will waste far more.

And even if it did take more in total, it would not be by much. This justification for saying it's not a wrong value is very weak.