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