DEV Community: Aoi Daniel Kaneda

【Flutter / Riverpod】container.read no mantiene vivo tu provider: la trampa de autoDispose en la prueba.

Aoi Daniel Kaneda — Fri, 23 Oct 2026 18:55:33 +0000

El autoDispose de Riverpod elimina automáticamente el estado de los providers que ya no tienen suscriptores. Es un mecanismo muy útil: ahorra memoria y evita errores causados por estados que quedan en la app sin querer.

Sin embargo, si no lo tenemos en cuenta al escribir pruebas, puede pasar que fallen aunque el código de producción sea correcto.

💻 Entorno de ejecución

Flutter 3.47.2
flutter_riverpod ^3.4.2
riverpod_annotation ^4.0.6
riverpod_generator ^4.0.8

📄 Código de ejemplo

Supongamos que preparamos testProvider y queremos verificar su comportamiento manteniendo TestState en una misma prueba. Sin embargo, con este código ambas pruebas fallan.

import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:flutter_test/flutter_test.dart';

Future<ProviderContainer> makeContainer() async {
  final container = ProviderContainer.test();
  await container.read(testProvider.future);
  return container;
}

void main(){
  test("inicialización", () async {
    final container = await makeContainer();
    final state = container.read(testProvider).requireValue;
    expect(state.count, 0);
  });

  test("se incrementa uno", () async {
    final container = await makeContainer();
    await container.read(testProvider.notifier).increment();
    final state = container.read(testProvider).requireValue;
    expect(state.count, 1);
  });
}

※TestNotifier / TestState

Agregamos Future.delayed en build para simular la llamada a una API o a la base de datos.

import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:flutter/foundation.dart';
part 'test_notifier.g.dart';

@riverpod
class TestNotifier extends _$TestNotifier {
  @override
  Future<TestState> build() async {
    await Future.delayed(const Duration(milliseconds: 5)); 
    return const TestState(count: 0);
  }

  Future<void> increment() async {
    final current = await future;
    state = AsyncData(TestState(count: current.count + 1));
  }
}

@immutable
class TestState {
  const TestState({required this.count});
  final int count;
}

🔍 ¿Por qué sucedió?

La causa es usar container.read para leer el estado del provider. container.read solo lee el valor actual y no se suscribe a sus cambios. Por eso, un provider con autoDispose queda sin suscriptores y se elimina automáticamente.

Hay que tener cuidado con los providers generados con @riverpod, porque tienen autoDispose activado por defecto.

Por ejemplo, la prueba de inicialización falla siguiendo este flujo:

Se crea el container con ProviderContainer.test().
await container.read(testProvider.future) crea el provider dentro del container y se ejecuta build.
Como el provider no tiene suscriptores, se elimina automáticamente durante el await.
container.read(testProvider) crea el provider otra vez.
Se llama a requireValue antes de que termine build, así que el AsyncValue todavía no tiene valor.
Se lanza una excepción y la prueba falla.

Mensaje de error
AsyncValueIsLoadingException: requireValue was called on the async value AsyncLoading TestState(), yet it neither has an error nor a value.

✅ Soluciones

Hay dos soluciones. Elige la que mejor se adapte a los requisitos de tu app.

1. Escuchar el provider con `container.listen()`

Este método consiste en suscribirse al provider mediante container.listen. No importa que el callback esté vacío: mientras la suscripción se mantenga, el provider no se elimina y su estado se conserve durante toda la prueba.

Future<ProviderContainer> makeContainer() async {
  final container = ProviderContainer.test();
  container.listen(testProvider, (_, _){});
  await container.read(testProvider.future);
  return container;
}

La documentación oficial de Riverpod también recomienda este método.

Be careful when using container.read when providers are automatically disposed.
If your provider is not listened to, chances are that its state will get destroyed in the middle of your test.
In that case, consider using container.listen.
Testing your providers | Riverpod

2. Dejar de usar `autoDispose`

La otra opción es desactivar autoDispose para que el estado del provider se mantenga aunque no tenga suscripciones.

@Riverpod(keepAlive: true) // <- cambiar keepAlive a true y regenerar
class TestNotifier extends _$TestNotifier {
  // igual que antes
}

Sin embargo, con este método el estado del provider también se mantiene en producción, lo que puede causar errores inesperados. Hay que llamar a ref.invalidate cuando se necesita reiniciar el estado, por ejemplo, al navegar a otra pantalla o al cerrar sesión.

🏁 Conclusión

En este artículo presenté una trampa oculta de autoDispose al escribir pruebas. Para trabajar con tranquilidad, lo recomendable es usar container.listen como base en las pruebas.

Poder escribir rápidamente pruebas robustas también influye directamente en la calidad del código de producción.

【Flutter】Cola secuencial + reintentos en Riverpod: por qué separé Notifier y AsyncNotifier.family

Aoi Daniel Kaneda — Thu, 01 Oct 2026 12:48:49 +0000

1. Contexto

Cuando desarrollo una aplicación con Flutter, a veces encuentro una función en la que se ejecuta secuencialmente el proceso asincrónico de cada línea registrada y luego se refleja su resultado.

Por ejemplo, este patrón se aplica a los casos siguientes:

Se cargan las imágenes a la vez, y después de analizarlas por IA, se muestran los resultados individualmente.
Después de que se escanean los códigos de barras, se consultan las existencias.

¿En este caso, cómo podemos implementarlo?

En este blog, voy a explicar cómo diseñar este requerimiento usando Riverpod.

2. Requisito Previo

Tenemos que considerar las cosas siguientes para que se satisfagan en la app:

Todos los ítems se ejecutan secuencialmente para que no pasen el límite de solicitudes.
Desde el punto de vista de rendimiento de renderizado, todos los ítems se reconstruyen solo según su estado.
El Notifier para gestionar cola secuencial funciona como el desencadenante del proceso asincrónico.
No se escribe una lógica sobre la administración del encolamiento, el orden del ejecución y el reintento en la capa de presentación para mantener la app testable y modificable.

3. Mi pensamiento

Primero, pensé que podría realizar este requerimiento con solo un Notifier.

(1) QueueNotifier que administra todos los ítems y el cambio de sus estados

Dejé de adoptar este método porque la lisa completa necesita reconstruirse cada vez que se completa un proceso.

(2) Cada ítem cambia su estado propio y observa el cambio

El segundo es que cada línea hace ref.watch de AsyncNotifier.family, y se ejecuta el método de Repository Class o UseCase Class a la hora de llamar a build() de este Notifier.
Sin embargo, cuando lo uso, 1) se ignora el orden de ejecución y 2) se generan muchos solicitud y puede alcanzar el límite de tasa.

(3) Uso dos Notifier para separar responsabilidades

El último método que consideré es usar dos Notifier. Un Notifier administra el proceso asincrónico en la cola general. Y el otro cambia el estado del ítem según su resultado. O sea, es un método híbrido entre (1) y (2).

Lo que más atención requiere es cómo se inicializa el estado del Notifier de (2). Si build() devuelve un valor vacío como valor inicial, no se puede distinguir si el resultado aún no ha llegado o ya llegó en la capa de presentación.

Por eso, utilizo Completer<Result>().future en build() y invoco un objeto de Future incompleto para expresar el estado en el que todavía no se termina.

Nota:

En este caso, se utiliza typedef TargetId = int como identificador de cada objeto a procesar. Si quiere usar un objeto como identificador, conviene utilizar los paquetes, Equatable o freezed, que le permiten expresar igualdad de valores.

4. Implementación

Implemento no solo ejecución secuencial mediante una cola sino también una funcionalidad de reintento que permite tocar un ítem cuyo procesamiento asíncrono falló por un error temporal, para volver a intentarlo.

Se busca lograr una integración bidireccional como la que se muestra en el siguiente diagrama.

Queue

QueueState

TargetStatus
Target
QueueState

typedef TargetId = int;

enum TargetStatus { pending, scanning, success, failure }

class Target {
  const Target({required this.id, required this.status});

  final TargetId id;
  final TargetStatus status;

  Target copyWith({TargetId? id, TargetStatus? status}) {
    return Target(id: id ?? this.id, status: status ?? this.status);
  }
}

@immutable
class QueueState {
  const QueueState({required this.targets});

  final List<Target> targets;

  QueueState updateStatus(TargetId id, TargetStatus status) {
    return copyWith(
      targets: [
        for (final target in targets)
          target.id == id ? target.copyWith(status: status) : target,
      ],
    );
  }

  Target? get firstPending {
    for (final target in targets) {
      if (target.status == TargetStatus.pending) {
        return target;
      }
    }
    return null;
  }

  QueueState copyWith({List<Target>? targets}) {
    return QueueState(targets: targets ?? this.targets);
  }
}

QueueNotifier

final queueProvider = NotifierProvider<QueueNotifier, QueueState>(
  QueueNotifier.new,
);

class QueueNotifier extends Notifier<QueueState> {
  bool _executing = false;

  @override
  QueueState build() => QueueState(
    targets: [
      for (int i = 0; i < 10; i++) Target(id: i, status: TargetStatus.pending),
    ],
  );

  Future<void> executeSequentially() async {
    if (_executing) {
      return;
    }
    _executing = true;

    final useCase = processUseCase();

    try {
      while (true) {
        final poppedTarget = state.firstPending;
        if (poppedTarget == null) {
          break;
        }

        state = state.updateStatus(poppedTarget.id, TargetStatus.scanning);

        try {
          final result = await useCase.execute(poppedTarget);
          ref
              .read(resultProvider(poppedTarget.id).notifier)
              .executed(Result(status: ResultStatus.success, data: result));
          state = state.updateStatus(poppedTarget.id, TargetStatus.success);
        } catch (e) {
          ref
              .read(resultProvider(poppedTarget.id).notifier)
              .executed(
                Result(status: ResultStatus.failure, message: e.toString()),
              );
          state = state.updateStatus(poppedTarget.id, TargetStatus.failure);
        }
      }
    } finally {
      _executing = false;
    }
  }

  Future<void> retry(TargetId id) async {
    state = state.updateStatus(id, TargetStatus.pending);
    await executeSequentially();
  }
}

Resultado

Result

ResultStatus
Result

enum ResultStatus{ success, failure }

@immutable
class Result {
  const Result({
    required this.status,
    this.data,
    this.message
  });
  final ResultStatus status;
  final Map<String, Object>? data;
  final String? message;
}

ResultNotifier

final resultProvider =
    AsyncNotifierProvider.family<ResultNotifier, Result, TargetId>(
      ResultNotifier.new,
    );

class ResultNotifier extends FamilyAsyncNotifier<Result, TargetId> {
  @override
  Future<Result> build(TargetId id) => Completer<Result>().future;

  void executed(Result result) {
    state = AsyncData(result);
  }

  Future<void> retry(TargetId id) async {
    state = const AsyncLoading();
    await ref.read(queueProvider.notifier).retry(id);
  }
}

Implementación en capa de presentación

Obtiene la lista completa desde QueueNotifier y el estado de cada ítem desde ResultNotfier. Así que el cambio del estado no provoca reconstrucción del otro.

 // Lista completa
final targets = ref.watch(queueProvider).targets;

 // Cada ítem
final asyncResult = ref.watch(resultProvider(target.id));
return asyncResult.when(
  loading: () => LoadingTile(),
  data: (result) => ResultTile(result),
  error: (e, _) => ErrorTile(),
);

5. Resumen

Completer<Result>().future permite expresar que el resultado aún no ha llegado sin renunciar a la seguridad de tipos.
Separar la gestión de la cola de la gestión del resultado permite acotar la reconstrucción parcial.
Se logra que la ejecución secuencial y el reintento convivan sin conflicto por una transición de estado bidireccional con el guard _executing en el lado de la cola y AsyncLoading en el lado del resultado.