StateNotifierProvider always refreshs when invalidated

[claudius-kienle]

Describe the bug
Once a StateNotifierProvider was created (e.g. via ref.watch(provider), it cannot be invalidated with ref.invalidate(provider), even though the widget that called ref.watch was disposed long ago and nothing else is listening.
I further analyzed the problem and figured out that the StateNotifierProvider is the only Provider calling ref.watch in their create() in base.dart:

class StateNotifierProvider<Notifier extends StateNotifier<State>, State>
...
  @override
  State create(ProviderElementBase<State> ref) {
    final notifier = ref.watch(this.notifier);

    void listener(State newState) {
      ref.setState(newState);
    }

    final removeListener = notifier.addListener(listener);
    ref.onDispose(removeListener);

    return ref.requireState;
  }
...

This call to ref.watch adds the _NotifierProvider, inialized during StateNotifierProvider's inialization, to the ProviderElement's _depenents once the StateNotifierProvider was created.

Later upon ref.invalidate, the StateNotifierProvider is refreshed since hasListeners is true in scheduler.dart:

void _performRefresh() {
  /// No need to traverse entries from top to bottom, because refreshing a
  /// child will automatically refresh its parent when it will try to read it
  for (var i = 0; i < _stateToRefresh.length; i++) {
    final element = _stateToRefresh[i];
    if (element.hasListeners) element.flush();
  }
}

To Reproduce
I created a minimal app which reproduces the bug. Just note the reaccuring state notifier initialized when clicking on Invalidate Providers.

Expected behavior
Expected behavior is that the StateNotifierProvider will not be refreshed as no listener (in the client code) is attached. Therefore, the ref.watch called in the create method must be disposed while the StateNotifierProvider is disposed.

I already created an issue (#1704) which did not describe the issue that clearly. Therefore, I closed that one to describe the bug in this issue in more detail.

[rrousselGit]

I'm pretty sure that what you're describing was fixed some long ago on master.

The dev release is quite out of date. I'd suggest trying the same thing with a git dependency on master to see if it still happens.

[claudius-kienle]

Yess indeed it is working successfully on the master branch.
I am wondering why exactly is the dev release so far behind?

[rrousselGit]

A released is planned today

[claudius-kienle]

A nice:) Thanks for your help!