Is this the generally accepted way to handle state on disposed AsyncNotifiers?

[joakimunge]

We've noticed some errors bubbling up to our general error handlers from our AsyncNotifiers:

Bad state: Future already completed

It seems to be because we're setting the state of already disposed providers. In this case, pressing a button which performs async ops, and then moving to another screen (disposing the button action controller). Here is a simplified code example of the method on the notifier:

  Future<void> follow(String userId) async {
    // {...}
    state = const AsyncLoading();
    state = await AsyncValue.guard(() async {
      await profileRepository.follow(userId);
      final profile = await profileRepository.getUser(userId);
      // Bad state error
      return profile;
    });
  }

Is the solution in #1879 suggested way to handle these cases? It seems like a lot of boilerplate to add to every autoDisposable notifier.

Is there a reason why this isn't done in the framework? I would think AsyncValue guard would catch this error, but it does not .

[joakimunge]

Little bump <3

[rrousselGit]

Providers should stop all operations when they are disposed. You shouldn't keep running logic after dispose

[joakimunge]

I understand, but should it be good practice to then always check if the provider is still alive? Meaning the boilerplate from #1879 should always be included on every provider.

At that point, wouldn't that be a good idea to handle within the framework?

[Colman]

I understand, but should it be good practice to then always check if the provider is still alive? Meaning the boilerplate from #1879 should always be included on every provider.

At that point, wouldn't that be a good idea to handle within the framework?

I agree with this. Why not just ignore attempts to modify the state after the provider has been disposed instead of throwing an error? You should never start a task that will modify the state once the provider has been disposed, but if the provider gets disposed while the task is running then we have to worry about cancelling it without having mounted checks everywhere. Why not just let the task run out and ignore its attempts to change state?

If this isn't going to be built into the framework, Shouldn't it be explained in the docs since you'd have to work around it in every async notifier that performs a side effect? https://riverpod.dev/docs/essentials/side_effects

[vasilich6107]

Hi @joakimunge @Colman
Did you find any suitable approach for this edge case?

[joakimunge]

Sadly not. We went with ahead with the boilerplate for the affected providers