Description
GitHub Issue: Generic ClientException on 401/403 Prevents Effective Retry Logic
When using http_interceptor
with a custom RetryPolicy
, the retry logic does not work correctly for 401 and 403 HTTP status codes. The issue arises because the client throws a generic ClientException
for these responses instead of allowing the response object to flow through. This causes the logic to be handled by shouldAttemptRetryOnException
rather than shouldAttemptRetryOnResponse
.
The ClientException
provides no meaningful details about the HTTP response (e.g., status code or headers), making it impossible to determine if the request should be retried. This severely limits the ability to implement token refresh or retry policies based on specific HTTP status codes.
Steps to Reproduce:
- Create a custom
RetryPolicy
class and implementshouldAttemptRetryOnResponse
to handle 401/403 responses. - Make an HTTP request that returns a 401 or 403 response.
- Observe that
_attemptRequest
throws aClientException
instead of passing the response toshouldAttemptRetryOnResponse
. - In
shouldAttemptRetryOnException
, theException
object lacks sufficient details to identify the HTTP status code.
Expected Behavior:
The library should allow responses with 401 and 403 status codes to be passed to shouldAttemptRetryOnResponse
for appropriate handling.
Actual Behavior:
The library throws a generic ClientException
with no meaningful information, forcing retry logic to rely on incomplete data in shouldAttemptRetryOnException
.
Example:
class ExpiredTokenRetryPolicy extends RetryPolicy {
@override
Future<bool> shouldAttemptRetryOnResponse(BaseResponse response) async {
if (response.statusCode == 401) {
return true;
}
return false;
}
}
final client = InterceptedHttp.build(
interceptors: [AuthHeaderInterceptorContract()],
retryPolicy: ExpiredTokenRetryPolicy(),
);
client.get('...'); // throws client exception
Environment:
- Flutter version: 3.24.5
http_interceptor
version: 2.0.0- Platform: Web
Additional Context:
The generic ClientException
in this case provides an error like "XMLHttpRequest error," which is not useful for making retry decisions.