Future provider memory leak about riverpod

[rrousselGit]

Oh, I think I got confused about the issue. I'll investigate. Sounds like a bug for sure.

Thanks for the report.

[rrousselGit]

It depends on the changes involved. But if it has to be a 3.0.0 fix, you could always stick to using your fork in the meantime

[rrousselGit]

All of that sounds normal to me.

A was mounted, and A is listening to B. So B is indeed listened.
Even though A is unused, it still needs to listen to B. After-all if B is recomputed, A will have to be recomputed the next time it is used.

[Colman]

I guess I just expected both A and B to be disposed when I leave the page and wait. I expected the state of B to be reset when I go back to the page the second time, but it remains. Why should a disposed resource A keep its dependencies B alive forever?

I find it weird that an unused auto-dispose provider leaves a listener attached to its dependency forever. This fundamentally causes a memory leak because if you:

1. Navigate to SomeScreen
2. Go back
3. Repeat steps 1-2 many times

In the end, you'll only have one SomeScreen mounted, so A will end up with one listener. B will have 1 useful listener and many other "ghost" listeners that are never cleared. So if those steps are repeated, you end up with 1 million listeners on B even though only one of them is for a resource that isn't disposed? There's no way that this can be expected behavior.

Why doesn't the watch method in A check if A is used/not disposed before adding the listener to B?

[Colman]

My project relies on this task being fixed urgently. If I were to make a PR and it's merged successfully, could it be a part of a minor release, or would it have to wait until 3.0?

[Colman]

I'm not exactly sure how to fix this. If provider a in my example is disposed since we left the screen, should it be allowed to watch anything? Or should a wait until it has no listeners and its build is completed before disposing?