In Riverpod 3, how would you cache an autoDispose product-detail provider for five minutes while never caching a failed request?

## What keepAlive does In an **autoDispose** provider, `ref.keepAlive()` suspends automatic disposal. It returns a **`KeepAliveLink`**: - While at least one link is open, the provider is not disposed even if nothing listens to it. - `link.close()` removes that link. When the last open link closes and the provider has no listeners, disposal is scheduled as usual. - If `keepAlive` is called several times, **all** links must be closed. - When the provider **recomputes** - a watched dependency changes, or it is invalidated - its links are dropped and automatic disposal is re-enabled for the new state. On a provider without `autoDispose`, there is nothing to suspend. ## Not caching failures The docs' own example is exactly this requirement: keep successful responses, drop failed ones. ```dart final productDetailProvider = FutureProvider.autoDispose.family<Product, String>((ref, productId) async { final api = ref.watch(catalogApiProvider); final product = await api.fetchProduct(productId); ref.keepAlive(); return product; }); ``` If `fetchProduct` throws, execution never reaches `keepAlive()`. The provider holds an error, and as soon as the product screen is closed, that error state is disposed; the next visit retries from scratch. A successful response pins the state. ## Adding an expiry Pinned forever is rarely what you want for product data. The docs build a reusable extension: ```dart extension CacheForExtension on Ref { void cacheFor(Duration duration) { final link = keepAlive(); final timer = Timer(duration, link.close); onDispose(timer.cancel); } } ``` Used after the await as `ref.cacheFor(const Duration(minutes: 5))`. Three details matter: 1. `Timer` comes from `dart:async`. 2. `onDispose(timer.cancel)` stops a stale timer if the provider rebuilds or is disposed before it fires. 3. If the provider was disposed during the request - the user left and the disposal ran - the `Ref` is no longer mounted and `keepAlive` would throw, so guard with `if (ref.mounted)` before caching. ## Counting from the last listener instead `cacheFor` counts five minutes from when the data arrived. To count from when the screen was closed, use the listener life-cycles: | Callback | Fires when | |---|---| | `ref.onCancel` | the provider loses its last active listener | | `ref.onResume` | it gains an active listener again after `onCancel` | | `ref.onDispose` | the state is destroyed or about to be rebuilt | The pattern: open a link after success, start a timer that closes it in `onCancel`, cancel that timer in `onResume`, and cancel it in `onDispose`. A user bouncing between the list and the product within five minutes never triggers a refetch. One subtlety: if the last listener left during the request, `onCancel` has already fired before you registered it, so check `ref.isPaused` after the await and start the timer at once if it is true. ## Choosing a strategy - **No cache**: plain `autoDispose`. - **Cache successes until the session ends**: `keepAlive()` after the await. - **Cache for N minutes after fetching**: `cacheFor`. - **Cache for N minutes after the screen closes**: `onCancel`/`onResume` with a timer. - **App-wide, never disposed**: drop `autoDispose` entirely. ## Common mistakes - Calling `keepAlive()` at the top of the body, before the request, which pins error states as well as successes. - Forgetting `onDispose(timer.cancel)`, so a timer from a previous build fires later and closes a link that belongs to nobody. - Using `keepAlive` on a provider without `autoDispose` and expecting any effect. - Opening several links in different places and closing only one, then wondering why the product never leaves memory.