Open Drvi opened 9 months ago
I've often seen retried requests succeed after initial timeouts. Including it by default as isrecoverable
makes sense to me.
Making isrecoverable part of the public API and mentioning it in the docs around Request retry arguments would also make sense with or without this change.
Could retry_check
provide such granular control when isrecoverable is false? What would a more simple runtime switch look like?
In https://github.com/JuliaWeb/HTTP.jl/pull/1110 we switched
isrecoverable(::Exception)
to be opt-in instead of opt-out, and we tried to include the exceptions we historically retried in older versions of HTTP. We didn't includeTimeoutExceptions
in that PR, but given some of the connection timeouts we've encountered in production, I think we want to retry those as well.What do others think?
In the future, ideally, we'd have more granular control over retries to make this a simple runtime switch.