Add public isrecoverable(::Exception) for retry classification (#1245)#1310
Merged
Conversation
Downstream packages (e.g. GitHub.jl) used HTTP.jl 1.x's private HTTP.RetryRequest.isrecoverable to decide whether a request exception is worth retrying. 2.0 dropped that module; the equivalent logic lived only in the private _retryable_request_error. Expose it as a documented public HTTP.isrecoverable(::Exception)::Bool that delegates to the same battle-tested classifier the built-in retry policy uses. Accepts either the underlying exception or the RequestRetryError wrapper passed to a retry_if callback, so downstream retry/backoff logic no longer has to reach into HTTP internals. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1310 +/- ##
=======================================
Coverage 87.31% 87.31%
=======================================
Files 29 29
Lines 11289 11291 +2
=======================================
+ Hits 9857 9859 +2
Misses 1432 1432 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Jun 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1245.
Downstream packages (notably GitHub.jl, reported by @DilumAluthge / @ericphanson) used HTTP.jl 1.x's
HTTP.RetryRequest.isrecoverable(::Exception)to decide whether a request-path exception is worth retrying. The 2.0 rewrite dropped that module, and the equivalent logic survived only in the private_retryable_request_error.This exposes it as a documented, public
HTTP.isrecoverable(::Exception)::Boolthat delegates to the same classifier the built-in retry policy uses — same name as the 1.x API to ease migration. It recognizes the transient transport/protocol failures (connection resets/EOF, socket errors, parse errors, dial/TLS-handshake timeouts, and the unwrapped causes ofOpError/TLSError), treats a hit request deadline as non-recoverable, and accepts either the raw exception or theRequestRetryErrorwrapper handed to aretry_ifcallback.Minimal surface: a thin public wrapper over the existing internal function (no logic change, internal call sites untouched), documented in the client API reference, with tests covering recoverable/non-recoverable classification, the wrapper, and parity with the internal classifier.
🤖 Generated with Claude Code