HTTP.rb offers us a way of configuring open timeouts, but there is no way to tell which timeout is what from the caller's point of view.
In some scenarios such as systems prone to occasional network intermittencies, singling out a short connection timeout to retry specifically for that case is often desirable. A catch-all retry strategy like we have today makes it hard to decide when to attempt a cheap and quick network intermittence retry from a long, target endpoint-health related write or read retry.
I'm proposing we introduce ConnectionTimeoutError as a subclass of TimeoutError so it becomes possible for the user to selectively catch open-time specific timeouts while maintaining compatibility with catch-all code currently using TimeoutError.
tarcieri
commented
2 years ago
HTTP.rb offers us a way of configuring open timeouts, but there is no way to tell which timeout is what from the caller's point of view.
In some scenarios such as systems prone to occasional network intermittencies, singling out a short connection timeout to retry specifically for that case is often desirable. A catch-all retry strategy like we have today makes it hard to decide when to attempt a cheap and quick network intermittence retry from a long, target endpoint-health related write or read retry.
I'm proposing we introduce
ConnectionTimeoutErroras a subclass ofTimeoutErrorso it becomes possible for the user to selectively catch open-time specific timeouts while maintaining compatibility with catch-all code currently usingTimeoutError.