Question 1

How do you fix "Could not find the correct Provider above this widget"?

Accepted Answer

Start from the mechanism: the lookup walks upward from the context, so the error never means "there is no provider" but "there is none above this context". A checking order: 1. Is the provider created inside that same widget? Then its own context cannot see it — you need a Builder or a separate child widget. 2. Is the read happening in a dialog, a showModalBottomSheet or a new route? Those build in their own route; read the value beforehand with read or pass it down with .value. 3. Is the provider below MaterialApp while the read is above it? 4. Is the type right? Registering Provider<TodoRepository> and reading a nullable or subclass type creates a mismatch. Close with a practical note: reading a nullable type turns the exception into null, but that hides the cause — I use it only for genuinely optional providers.

Question 2

The user closes the screen before an async operation finishes. How do you handle that with Provider?

Accepted Answer

Name the problem precisely: the notifier has been disposed while the request is still in flight; touching state and calling notifyListeners() when it returns throws. Fixes, strongest first: 1. Extend the object's lifetime — place the model above the screen if the result is genuinely needed (say it will be cached). 2. Cancel the request — a CancelToken (dio) or StreamSubscription.cancel(); the cleanest option because the wasted work actually stops. 3. Guard it — set a flag in dispose and skip touching state after the await. Simple, but the work continues. 4. On the widget side — check mounted before using a BuildContext. Add in an interview: Riverpod reduces this at architecture level — an autoDispose provider gives you ref.onDispose as a cleanup point, and Ref.mounted lets you check the provider is still alive after an await.

Question 3

What are the most criticised weaknesses of Provider?

Accepted Answer

Give a balanced answer — the package is still a Flutter Favorite and works in millions of projects. Weaknesses: Lookup by type — a missing provider fails at runtime, and with two providers of the same type which one you read depends on the shape of the tree. ChangeNotifier encourages mutability — which leads to the mistakes that break ==-based optimisations like select. Async state is hand-rolled — loading/error flags live inside the model, in each team's own style. Dependence on BuildContext — dialogs, routes and initState are a permanent source of traps. Then show the other side: little boilerplate, a simple mental model, the official example in Flutter's own docs, and the foundation of flutter_bloc. Conclusion: "For small and medium apps Provider is still the right choice; the problems start as the codebase grows and the share of async work rises — that is where I draw the line."

Error	Cause	Fix
`ProviderNotFoundException` — "Could not find the correct Provider<T> above this widget"	The read uses a `context` that has no such provider above it (for example the context of the widget that creates the provider, or a dialog/route context outside it)	Move the provider higher, or obtain a new `context` for the subtree via a `Builder` or a separate widget
"A ChangeNotifier was used after being disposed"	An existing object was handed to `create` and the provider disposed it; or an async operation returns after disposal and calls `notifyListeners()`	Use `.value`; after async work, check the object is still alive
"setState() or markNeedsBuild() called during build"	`notifyListeners()` fires during `build` — for instance a method is invoked from inside `build`	Move the load to `initState`/`didChangeDependencies`, or defer it by one frame
The UI never updates	`read` was used in `build`; or `notifyListeners()` was never called; or `select` returns a mutable value	Switch to `watch`/`Consumer`; select an immutable value

Typical mistakes and error messages

📚 Sources and documentation