clear method
Empties both caches, cancelling in-flight fetches and every gcTime
timer. This is the teardown call: a widget test ends with it, since
Flutter's test binding asserts that no timer outlives the tree.
Observers are not stopped: a subscribed observer — a polling one in
particular — rebuilds its query on its next interaction and keeps
fetching. Destroy the observers first (the Flutter binding's controllers
do that in dispose, so a torn-down tree leaves none), then clear.
A pending mutation dropped here fails — with a CancelledError if it
was paused, with its own outcome if a request was in flight — and its
error or success callbacks run a few microtasks after this returns.
A callback that writes to the cache, an optimistic update's onError
rollback above all, then re-creates the query it names, gc timer
included: clear() empties the caches, it does not seal them, and a
write after it is a write like any other. (TanStack Query never runs
those callbacks because it abandons a paused mutation for good; here
the caller of mutateAsync is told.) A teardown that must leave
nothing pending lets the callbacks run and clears once more — the
widget-test teardown the Flutter binding documents does. A mutation
restored from persistence and never continued has no request of its
own: it is dropped without running and without failing — and dropping
a restored scope queue starts none of it, whatever the network says.
One batch for both caches, so a subscriber wrapped in
notifyManager.batchCalls — the documented way to defer delivery —
gets one scheduled flush for the call rather than one per entry
removed. The batching is here rather than on QueryCache.clear because
a cache holds no notify manager: the manager belongs to the client.
Implementation
void clear() {
notifyManager.batch(() {
queryCache.clear();
mutationCache.clear();
});
}