Blake Leonard<p><span>More </span><a href="https://infosec.town/tags/dart" rel="nofollow noopener noreferrer" target="_blank">#dart</a><span> troubles today, this time particularly with </span><a href="https://infosec.town/tags/riverpod" rel="nofollow noopener noreferrer" target="_blank">#riverpod</a><span>.<br><br>It looks like sometimes, with an unknown cause, setting a StateNotifier-based provider that holds an error message from within a ConsumerWidget (in response to another provider) will fail, because "Providers are not allowed to modify other providers during their initialization."<br><br>The only provider that should be being initialized is the command provider, and I've taken it out of the equation by delaying the set until that is done executing. The behavior hasn't changed at all. Oddly enough, once that error grinds through the debugger, it actually sets the StateNotifier to a resulting error ("At least listener [sic] of the StateNotifier Instance of '_CommandNoteNotifier' threw an exception<br>when the notifier tried to update its state"; the console shows that that error is in response to the "Providers are not allowed" error). I just don't know where exactly that's happening, or why that works. Or how I can get it to work correctly.<br><br>Would it work fine if I took executeCommand (which now-indirectly runs the "set") to not be a Provider and just be a function that takes a ref instead? That's not preferable because then I have to take a WidgetRef outside of a widget, which is "wrong" to do and comes with other issues.</span></p>