invalidateQueries predicate option: queryKey property is typed too strictly

[vikingandrobot]

Describe the bug

When using the invalidateQueries method of the QueryClient, the queryKey is typed a bit too strictly in the predicate method that we pass to it through the QueryFilters parameter.

When "exact" is false, the queryKey filter is not an exact match, so the queries passed to the predicate option can contain query keys that have a different type from the type of the top-level queryKey. The latest version of the library however types it as the exact same type as the provided queryKey.

In the minimal reproducible example, this is highlighted using a const array of string as query key and the type of the queryKey in the predicate function being the exact same type, even though it could be any other array starting with the same string and then containing any unknown values.

Your minimal, reproducible example

https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgRQK4FMoE8DCAbYdAO3gF84AzKCEOAcgAEYBDIgZxYGMBrAeinTNOMALQBHDNjoBuAFCzOEdvG7oscALxwA2nQAmEAOZs6AXThxmbOIuVzevOADkIcTNSiyi6AO4pJuATEMAAUAJQAdMBEAG7MBHrMMOhomIRsIQiyFhKYWADSagBccKpYADTZbgAeQjAlFPFs6JUWYAJ6wJxJ6CUhudhhmgB8iFUWDnAAssyqcGw06KXRenAQFDYAFug8a0RwMNtwAhxrG4dLA+plNgI91qxuUB7jcMAb-QERV4VY2gCM5g0wPoEB83igdCGWQssOO6BgqCg+0aeGacjhpHkcIEiORBygGAxcCxpDCciAA

Steps to reproduce

The Typescript error is visible in the playground and in the errors panel on the right.

Expected behavior

I would expect the type of the queryKey value in the predicate method to only be so strict when the "exact" option is true, or to always be less strict by only stating that it starts with the same values as the provided queryKey in the QueryFilter.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

macOS, Typescript 5.8.2

Tanstack Query adapter

None

TanStack Query version

5.67.1

TypeScript version

5.8.2

Additional context

No response

[TkDodo]

@Nick-Lucas I think we talked about that filters should only narrow query when it comes from queryOptions, but even then, only if exact is set to true. I think we got this wrong somewhere

[Nick-Lucas]

Hm yeah sounds like an oversight, I probably didn't consider it as I honestly wasn't aware of the significance of exact

[TkDodo]

so everything we did with QueryFilters being inferred from queryKey in invalidateQueries and friends should only work if exact:true is specified (exact:false is the default behaviour). Is this really worth it? seems like a quite narrow use-case... What do you actually do with this in trpc @Nick-Lucas ?

[TkDodo]

because, if you pass:

queryClient.invalidateQueries({ queryKey, exact: true })

then you don’t need a predicate filter at all, because you’re already exactly matching a key. Feels to me like we should revert that and just have the key always be QueryKey ?

[Nick-Lucas]

So maybe the solution is to not type the predicate at all? it's either a known type in which case it's useless, or an unknown type which can't easily be typed? Though in truth in tRPC we probably could put a union type in there for pathFilter/pathKey I just haven't been sure it's worth it, predicate isn't something I've personally found a use case for

[TkDodo]

Yeah I don't think we should type it in query, it should just be QueryKey