<story><title>Don&apos;t trust default timeouts</title><url>https://robertovitillo.com/default-timeouts/</url></story><parent_chain></parent_chain><comment><author>joosters</author><text>No! The danger in forcing programmers to pick a timeout is that they will pick the wrong value, most often a too short timeout, because they have been testing their software on a super-fast internal network and haven&amp;#x27;t considered the poor users in the real world.&lt;p&gt;Case in point: Google&amp;#x27;s Waze. If I have a slow mobile connection (e.g. edge or even 3g), Waze will repeatedly fail to load a driving route. It will think for a few seconds at most, then timeout and tell me there was a problem. If it only would wait a few more seconds to load, then the app would be useful. Instead, due to their crappy choice of timeouts, the app becomes useless.</text></comment>
<story><title>Don&apos;t trust default timeouts</title><url>https://robertovitillo.com/default-timeouts/</url></story><parent_chain></parent_chain><comment><author>emptysea</author><text>Related to HTTP timeouts, I’ve run into database clients without default timeouts. This meant even though the HTTP request was cut off after the timeout, the database request kept on working causing tons of slow database requests to be running on the server.&lt;p&gt;With Postgres you can use roles to set timeouts, maybe you want a longer timeout for crons, shorter for HTTP endpoints.&lt;p&gt;Sadly we were using mongo which doesn’t have equivalent functionality. Ended up monkey patching the client library to define a reasonable default timeout.</text></comment>