Possible issue with v3 RetryPolicy

[JNemra]

After returning true from shouldAttemptRetryOnResponse, the interceptor is called for the retry request but it never reaches the server. This works correctly in v2. Here are my logs:

I/flutter (20981): 🔐 [AuthInterceptor] Intercepting: https://192.168.1.2:7052/api/groups?pageIndex=1&pageSize=20&totalItemsCountRequired=true
I/flutter (20981): 🔐 [AuthInterceptor] Token: eyJhbGciOiJIUzI1NiIs...
I/flutter (20981): 🔍 [RetryPolicy] Response: 401 for https://192.168.1.2:7052/api/groups?pageIndex=1&pageSize=20&totalItemsCountRequired=true
I/flutter (20981): 🔍 [RetryPolicy] Request type: Request
I/flutter (20981): 🔄 [RetryPolicy] 401 detected!
I/flutter (20981): 🔑 [RetryPolicy] Starting token refresh...
I/flutter (20981): 🔐 [AuthInterceptor] Intercepting: https://192.168.1.2:7052/api/account/refreshToken
I/flutter (20981): 🔐 [AuthInterceptor] Token: eyJhbGciOiJIUzI1NiIs...
I/flutter (20981): 🔍 [RetryPolicy] Response: 200 for https://192.168.1.2:7052/api/account/refreshToken
I/flutter (20981): 🔍 [RetryPolicy] Request type: Request
I/flutter (20981): ⏭️ [RetryPolicy] Skipping retry for refresh/logout
I/flutter (20981): 🔑 [RetryPolicy] Refresh success: true
I/flutter (20981): 🔑 [RetryPolicy] New token: eyJhbGciOiJIUzI1NiIs...
I/flutter (20981): 🔄 [RetryPolicy] Will retry: true
I/flutter (20981): 🔐 [AuthInterceptor] Intercepting: https://192.168.1.2:7052/api/groups?pageIndex=1&pageSize=20&totalItemsCountRequired=true
I/flutter (20981): 🔐 [AuthInterceptor] Token: eyJhbGciOiJIUzI1NiIs...

Expected: Request should be sent to server with new token
Actual: Nothing happens - request never reaches server

Is this expected behavior or a bug? Let me know if you need more information."

Environment:

• http_interceptor: 3.0.0 (issue) vs 2.0.0 (works)
• Flutter: 3.41.7
• Dart: 3.11.5

[CodingAleCR]

Thank you, I'll look in detail into this and give you an answer as soon as I can. I appreciate the notes and the issue.

[itsUndefined]

Looked into this — it reproduces, and it's a real regression in 3.0.0, not expected behavior. Once a request has been sent, a retry requested via RetryPolicy cannot be carried out, because the retry re-sends the same, already-finalized BaseRequest.

Root cause

InterceptedClient.send (lib/src/client/intercepted_client.dart) wires retries with a closure that captures one fixed request:

final streamed = await executeWithRetry(
  policy: _retryPolicy,
  request: request,
  attempt: () => _execute(request),   // same `request` instance on every call
);

executeWithRetry (lib/src/retry/retry_executor.dart) re-invokes attempt() for each retry, and _execute ends in _client.send(interceptedRequest). With no copyWith in the v3 core and interceptors documented to "mutate in place / return the same instance", interceptedRequest is the same BaseRequest object on every attempt.

Every real inner client calls request.finalize() inside its send(), and package:http's BaseRequest.finalize() throws if the request was already finalized:

Bad state: Can't finalize a finalized Request.

So: attempt 1 finalizes the request → shouldAttemptRetryOnResponse returns true → attempt 2 re-sends the same finalized request → StateError.

One extra wrinkle: that StateError is an Error, not an Exception, so executeWithRetry's } on Exception catch does not catch it — it escapes send() uncaught.

This worked in 2.x because _attemptRequest rebuilt the request (copyWith) on each attempt and recursed with the original, un-finalized request, so every attempt sent a fresh request.

Reproduction (no network)

The inner client below does exactly what IOClient does in send() — calls request.finalize():

import 'dart:async';
import 'dart:convert';
import 'package:http/http.dart';
import 'package:http_interceptor/http_interceptor.dart';

class FinalizingClient extends BaseClient {
  int sends = 0;
  @override
  Future<StreamedResponse> send(BaseRequest request) async {
    request.finalize(); // real HTTP clients finalize here
    sends++;
    return StreamedResponse(
      Stream<List<int>>.value(utf8.encode('{"error":"server"}')),
      500,
      request: request,
    );
  }
  @override
  void close() {}
}

class Noop implements HttpInterceptor {
  @override
  FutureOr<BaseRequest> interceptRequest({required BaseRequest request}) => request;
  @override
  FutureOr<BaseResponse> interceptResponse({required BaseResponse response}) => response;
  @override
  FutureOr<bool> shouldInterceptRequest({required BaseRequest request}) => true;
  @override
  FutureOr<bool> shouldInterceptResponse({required BaseResponse response}) => true;
}

class RetryOn500 implements RetryPolicy {
  @override
  int get maxRetryAttempts => 1;
  @override
  FutureOr<bool> shouldAttemptRetryOnException(Exception reason, BaseRequest request) => false;
  @override
  FutureOr<bool> shouldAttemptRetryOnResponse(BaseResponse response) => response.statusCode >= 500;
  @override
  Duration delayRetryAttemptOnException({required int retryAttempt}) => Duration.zero;
  @override
  Duration delayRetryAttemptOnResponse({required int retryAttempt}) => Duration.zero;
}

Future<void> main() async {
  final inner = FinalizingClient();
  final client = InterceptedClient.build(
    interceptors: [Noop()],
    retryPolicy: RetryOn500(),
    client: inner,
  );
  try {
    final res = await client.get(Uri.parse('https://example.test/api/thing'));
    print('HTTP ${res.statusCode}, inner send()s: ${inner.sends}');
  } catch (e) {
    print('threw ${e.runtimeType}: $e  (inner send()s: ${inner.sends})');
  }
}

Output on http_interceptor: 3.0.0:

threw StateError: Bad state: Can't finalize a finalized Request.  (inner send()s: 1)

The identical program on 2.0.0 prints HTTP 500, inner send()s: 2 — the request is replayed.

Consequence: the "Retrying requests" example in the README (refresh token on 401, return true) cannot work in 3.0.0 for any request that has already reached an inner client.

Possible direction

executeWithRetry needs a fresh BaseRequest for each attempt rather than re-sending one instance — e.g. rebuild the request inside send / _execute per try, or pass a request factory into executeWithRetry instead of a single request. Note StreamedRequest / MultipartRequest can't be replayed regardless (single-consumption stream bodies), so those would still need to be excluded from retry.

---

This report was AI-generated by Claude Opus 4.7.