Does riverpod provide "FIFO"-like behaviour for its notifier methods?

[fulstadev]

Let's say you have implemented a riverpod notifier class which holds a list of instances of a class in its state. That notifier class then also has a variety of different notifier methods which update the state by removing / adding list elements in multiple different ways. Some of them are asynchronous.

Let's say that your app then calls these notifier methods in a variety of different contexts / widgets, depending on whatever task executed in your app. That makes it possible that one of these asynchronous notifier methods may be called while another one is still running.

What I'm afraid of is that if two methods are called at nearly the same time (e.g., from different contexts in the app), and these methods both read from the state and then modify it: Could they overwrite each other's changes?

Or does riverpod implement some kind of FIFO-logic for this, to assure that notifier methods of the same notifier are always executed one after the other?

If riverpod does not assure this, I guess we'd have to implement some kind of logic which "queues" all notifier calls via a (thus only) public method of the notifier, and then performs these state updates one-by-one internally by using a Queue and accordingly private notifier methods scoped to an internal use of the notifier only. To assure that there won't be any of the above-mentioned race-conditions. But we wondered if that is not already provided anyways, by the package?

[rrousselGit]

There's no such thing, at least for Notifier methods.

But there could be one. Riverpod recently added mutations. It could be in the scope of mutations to allow only a single method to run at once.

[fulstadev]

@rrousselGit Thanks for your quick reply, good to know! Are you referring to this, or could you elaborate how mutations could solve the problem of async notifier call concurrency?

Also, if I may ask, are you planning on implementing such a thing, sth like this? That would be a total gamechanger I guess! I came across this post too, and I guess that in your comment:

1.) StateNotifier with multiple async actions that manipulate state sequentially:

Depends on the case more specifically. It could be that you can refactor it such that the problem disappears,

...by 'refactor' you mean either by implementing a custom event Queue handling one notifier call after the other, or trying to avoid async notifier methods entirely (which is in my case not possible, unfortunately)?

[lishaduck]

Are you referring to this, or could you elaborate how mutations could solve the problem of async notifier call concurrency?

No, he's not. That's an unofficial package for mutations on riverpod v2. He's referring to the upcoming feature in riverpod 3, see #1660.
Instead of calling notifier methods, you'd call mutations, which riverpod could enqueue for you.

Also, if I may ask, are you planning on implementing such a thing, sth like this? That would be a total gamechanger I guess!

I interpreted his comments as being that he feels that those solutions are better left in userland, and you should manage a queue, etc, manually.
Given that he's filed an issue for this, I think mutations have change his mind somewhat (#3887).

(I just wanted to clarify that riverpod_mutations is an unofficial version)