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.
Installation
Add the package to your Flutter project.
flutter pub add flutter_resilient_http:^1.0.0Quick Start
Start with this small example, then connect it to your own application. Read the known limitations before using it with real data.
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 referenceExample & 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.
git clone https://github.com/lekthedeveloper/flutter_resilient_http.git
cd flutter_resilient_http
flutter pub get
flutter testFrequently 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.