Skip to content

Build failed due to extending RetyPolicy on package version 3.0.0 #175

@kasimr-oxc

Description

@kasimr-oxc

Describe the bug
The build fails with the following error when attempting to extend RetryPolicy in a custom HTTP interceptor:

Error: The class 'RetryPolicy' can't be extended outside of its library because it's an interface class.
class HttpRetryPolicy extends RetryPolicy {

The issue occurs during the kernel snapshot build step. It seems that RetryPolicy is defined as an interface class in its original library, which prevents extending it in another file. This is likely a breaking change introduced with Dart 3’s new class modifiers (interface, base, final).

To Reproduce
Steps to reproduce the behaviour:

  1. Create a custom retry policy by extending RetryPolicy from the http_interceptor package:
    import 'package:http_interceptor/http_interceptor.dart';
    
    class HttpRetryPolicy extends RetryPolicy {
      @override
      Future<bool> shouldAttemptRetryOnResponse(BaseResponse response) async {
        // custom logic
        return false;
      }
    }
  2. Use this policy in an interceptor or directly with InterceptedClient.
  3. Run flutter build (or any command that triggers kernel compilation, e.g., flutter run).
  4. See the build error.

Expected behaviour
Developers should be able to extend RetryPolicy to provide custom retry logic, as was possible in earlier versions of the package. The build should succeed without errors.

Screenshots
Not applicable.

Please complete the following information):

  • Flutter version: 3.41.9
  • IDE: VS Code / IntelliJ IDEA (not relevant)
  • http_interceptor Version 3.0.0

Additional context
This error is caused by the new Dart 3 class modifiers. The RetryPolicy class in the http_interceptor package is declared as interface, which means it can only be implemented (implements) but not extended outside its defining library. To allow custom retry policies, the package author should either remove the interface modifier or change it to base (if extension is intended but requires marking subclasses as base as well). Alternatively, end users can switch from extends to implements, but that forces re-implementation of all abstract members and may break existing codebases.

Possible workaround
Until the package is updated, use implements RetryPolicy instead of extends, and manually implement all required methods (not just the overridden ones). This is not ideal for complex policies but unblocks the build.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions