useQuery is crashing if clientId is set in the options

[tukanoidd]

Describe the bug
I'm working on a web app. I need to mock graphql requests in those tests. I use mock-apollo-client with @vue/apollo-composables. It only breaks in tests, not dev/production builds, and only when clientId is set manually (including literal "default" value) in the useQuery call.

Expected behavior
It just works?

Versions
vue: ^3.3.13
vue-apollo: ^4.0.1
@apollo/client: ^3.9.4
@vue/apollo-composable: ^4.0.1

Additional context
After hours of searching for information and debuggin the code, I think I found the source of the issue:

apollo/packages/vue-apollo-composable/src/useApolloClient.ts

Line 46 in 6fa46ab

const providedApolloClients: ClientDict<TCacheShape> | null = inject(ApolloClients, null)

from the code it's see that by default it just sets the clients dict to null and for some reason decides to use that first to see if it can find the client. But because providedApolloClients is null, the resolveClientWithId function throws an error (

apollo/packages/vue-apollo-composable/src/useApolloClient.ts

Line 27 in 6fa46ab

throw new Error(`No apolloClients injection found, tried to resolve '${clientId}' clientId`)

), making this check (

apollo/packages/vue-apollo-composable/src/useApolloClient.ts

Line 52 in 6fa46ab

if (client) {

) obsolete and not going forward with checking savedCurrentClients, which provideApolloClients actually sets, while resolveDefaultClient, which gets called in cases where clientId isn't defined, doesnt throw but instead just uses undefined (

apollo/packages/vue-apollo-composable/src/useApolloClient.ts

Line 21 in 6fa46ab

: (providedApolloClient ?? undefined)

) and allows the logic to continue with accessing savedCurrentClients (

apollo/packages/vue-apollo-composable/src/useApolloClient.ts

Line 61 in 6fa46ab

return resolveDefaultClient(savedCurrentClients, savedCurrentClients.default)

), where it ultimately gets the default client.

Proposed solution
Don't throw in resolveClientWithId and use a similar hack like in resolveDefaultClient, or throw the error after both resolvers fail, not after the first one.

EDIT: pretty sure it's the same issue as here, although I might be wrong