queryCache.findAll() returns wrapped iterable instead of array — breaks standard invalidation APIs

[nicolas-chalet-wmx]

Environment:

• @tanstack/react-query v5.90.2
• React 18.2.0
• Issue occurs in mobile WebViews only, not in Electron

Description:

We're building a library that uses react-query and is consumed by a host application. In certain build configurations (mobile WebViews), we observe unexpected behavior:

const queryCache = useQueryClient().getQueryCache();
const queries = queryCache.findAll();

// Expected: Query[]
// Actual: An array with a single iterable entry that yields Query objects

We suspect this is due to module duplication where our library and the host app resolve to different instances of @tanstack/react-query.

Impact:

Due to this issue, we cannot use the standard react-query APIs for cache management:

// ❌ These do NOT work in our mobile environment:
queryClient.invalidateQueries({ queryKey: ['myKey'] });
queryClient.resetQueries({ queryKey: ['myKey'] });
queryClient.clear();

// ✅ We have to manually iterate and call methods on each Query instance:
const queries = queryCache.findAll();
const normalized = normalizeIterableResult(queries); // our workaround

normalized.forEach((query) => {
  query.invalidate();
  query.reset();
  // or query.fetch() for refetch
});

This forces us to bypass the intended API and work directly with Query instances, which feels brittle and may break with future versions.

Questions:

1. Is this a known behavior when multiple instances coexist?
2. Are there recommended bundler configurations to prevent this?
3. Should react-query detect this scenario and warn developers?
4. Is working directly with Query.invalidate() / Query.reset() / Query.fetch() a supported pattern, or are we relying on internal implementation details?

Workaround:

We currently normalize the result by checking if the first element is iterable:

const normalizeQuery = (maybeNotQuery: Query): Query[] => {
  const isIterator = Symbol.iterator in Object(maybeNotQuery);
  if (isIterator) {
    return [...maybeNotQuery as Iterable<Query>];
  }
  return [maybeNotQuery];
};

const queries = queryCache.findAll().flatMap(normalizeQuery);

[aniruddhaadak80]

@nicolas-chalet-wmx Thanks for the detailed environment notes (especially WebView-only repro).

queryCache.findAll() returning a non-array-like wrapper in one build target strongly suggests an interop/transpilation mismatch (iterator/polyfill/runtime) rather than expected Query API behavior.

Quick isolation steps:

1. log Array.isArray(queryCache.findAll()) and constructor/type in both environments
2. wrap with Array.from(...) before downstream invalidation logic
3. compare transpilation/polyfill targets between Electron and WebView bundles

If this confirms environment-specific iterator behavior, maintainers can likely suggest the most compatible workaround.

References:

• https://tanstack.com/query/latest/docs/framework/react/reference/QueryCache
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/from

[travisbreaks]

You have diagnosed it correctly: module duplication. Your library and the host app are resolving to different instances of @tanstack/react-query, so they have different class prototypes. findAll() returns objects from the library's instance, and Array.isArray() can fail across module boundaries.

This is especially common in WebViews where the library is pre-bundled with react-query inlined, while the host app has its own copy.

The real fix is deduplication. In your library's package.json, mark react-query as a peer dependency and externalize it from the bundle:

// library vite.config.ts
export default defineConfig({
  build: {
    lib: { entry: "src/index.ts", formats: ["es"] },
    rollupOptions: {
      external: ["@tanstack/react-query", "react", "react-dom"],
    },
  },
})

If you cannot change the library, the host app can force deduplication: resolve: { dedupe: ["@tanstack/react-query"] } in Vite, or resolve.alias pointing to require.resolve("@tanstack/react-query") in Webpack.

Your Array.from() workaround is fine as a stopgap, but the bundling fix is what actually solves it.