clear method

void clear()

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();
  });
}