This brings the default behavior in line with other FoundationDB client
libraries which don't use client-side timeouts when waiting for futures to
fire.
A few other reasons are:
Currently we may generate spurious future ready messages when timeouts
fire during overload scenarios. The caller would have to know to flush ready
messages if they caught a {timeout, _}
The response may succeed under 5 seconds, but it would be queued in the
networking layer and throw a timeout error on the Erlang side.
Timeouts can be set as a transaction or db handle options. It's easier to
apply configuration defaults there than for individual wait functions.
Watch futures are not bound by the 5 second transaction time limit, and
they'd have to know about the default wait/1,2 call timeout to know to
extend it or set it to infinity.
This brings the default behavior in line with other FoundationDB client libraries which don't use client-side timeouts when waiting for futures to fire.
A few other reasons are:
Currently we may generate spurious future
readymessages when timeouts fire during overload scenarios. The caller would have to know to flush ready messages if they caught a{timeout, _}The response may succeed under 5 seconds, but it would be queued in the networking layer and throw a
timeouterror on the Erlang side.Timeouts can be set as a transaction or db handle options. It's easier to apply configuration defaults there than for individual wait functions.
Watch futures are not bound by the 5 second transaction time limit, and they'd have to know about the default
wait/1,2call timeout to know to extend it or set it toinfinity.