Skip to main content
OAOlamilekan AdeyemiFlutter · React · Next.js · Full-Stack DeveloperHire Me
All packages/Networking/flutter_resilient_http
Networking

flutter_resilient_http

HTTP request handling with retry backoff, a circuit breaker and an offline request queue.

HTTPRetryCircuit BreakerOffline Queue
v1.0.0Documented version
MITOpen source license
Flutter & DartSee platform notes

Overview

Give your app one place to configure HTTP retries, observe failures and queue supported requests while offline.

flutter_resilient_http wraps the standard Dart HTTP client with configurable retries and optional failure handling. Start with ordinary read requests, then introduce circuit and queue behavior deliberately, with tests for the failure cases your app can encounter.

HTTP
Retry
Circuit Breaker
Offline Queue

Installation

Add the package to your Flutter project.

bash
flutter pub add flutter_resilient_http:^1.0.0

Quick Start

Start with this small example, then connect it to your own application. Read the known limitations before using it with real data.

dart
import 'package:flutter_resilient_http/flutter_resilient_http.dart';

Future<void> main() async {
  final client = ResilientHttpClient(
    retryPolicy: const RetryPolicy(
      maxRetries: 3,
      initialDelay: Duration(milliseconds: 500),
      useJitter: true,
    ),
  );
  try {
    final response = await client.get(
      Uri.parse('https://api.example.com/data'),
    );
    print('Status: ' + response.statusCode.toString());
  } finally {
    client.close();
  }
}

This is a starting point, not a complete application. Add error handling and tests for your own backend and lifecycle.

Configuration

Construct a RetryPolicy and pass it to ResilientHttpClient. You can also supply innerClient, circuitBreaker, offlineQueue, isOffline and onLog.

Use the connectivity callback to report your app’s offline state. This package does not monitor connectivity for you. Keep logs free of credentials.

Retry Strategy

The default policy allows three retries after the first attempt, starting at 500 milliseconds with a backoff factor of two. Default retry status codes are 408, 429, 500, 502, 503 and 504.

Use shouldRetryResponse and shouldRetryError to narrow the retry conditions. In 1.0.0, jitter is applied after the maximum delay cap, so the final delay can exceed that cap. Mutation retries need an idempotency policy on your server.

Circuit Breaker

An optional CircuitBreaker wraps request execution. Configure a failure threshold and reset timeout, and observe transitions using its callback.

Important: the current client returns a final HTTP 5xx response normally, so the breaker does not count that response as a thrown failure. Do not assume repeated 5xx responses will open the circuit in version 1.0.0.

Offline Queue

Supply an OfflineRequestQueue and an isOffline callback. Supported mutation requests can be queued while offline. Call flushOfflineQueue() when your application decides it is safe to retry.

The queue is memory only and does not survive process termination. Streamed and multipart request handling needs extra care. Do not use it as the sole record of an order, payment or other important change.

Known Limitations

Version 1.0.0 has known limitations: a final HTTP 5xx response does not currently trip the circuit breaker, and the offline queue is held in memory. Avoid automatically replaying payments or other mutations without server side idempotency.

API Reference

Explore the public classes, methods and constructors for version 1.0.0.

Open versioned API reference

Example & Tests

Use the repository example to explore the package in context. Run its tests locally, and add regression cases for the known limitations above. The SSL package’s device test results do not apply to this package.

bash
git clone https://github.com/lekthedeveloper/flutter_resilient_http.git
cd flutter_resilient_http
flutter pub get
flutter test
View repository example

Frequently Asked Questions

Can I use this package in a commercial app?

The package is MIT licensed. Follow the license terms and review the current limitations for your use case.

Where should I report a bug?

Open an issue in the package repository. Include the package and Flutter versions, a minimal reproduction and the expected behavior. Remove credentials and private data.

Are these packages all verified for production?

No blanket guarantee is made. Each guide documents its current limitations. Test your integration and use independent review for sensitive workflows.