`useLazyQuery` cache overwrites results when multiple queries with different variables are executed before completion

[TienThinh-fe]

Issue Description

When using useLazyQuery to execute the same query with different variables in quick succession (before the first query completes), Apollo Client's InMemoryCache only stores the result of the last query. Previous query results are lost and require re-fetching, even though they should be cached independently based on their different variable values.

This issue affects production applications where users interact rapidly with filter components, causing:

• Data loss in both Apollo cache and application state
• Unnecessary network requests for previously fetched data
• Poor user experience with inconsistent loading states

Expected Behavior
Both queries should complete and cache their results independently based on their variable values. Subsequent calls with the same variables should use cached data without making network requests.

Actual Behavior
Only the last query's result is cached. Previous query results are lost from the cache, causing unnecessary re-fetching when those queries are triggered again.

Link to Reproduction

https://github.com/TienThinh-fe/apollo-lazy-issue

Reproduction Steps

Clone the repo

Backend

cd backend && npm install && npm start

Frontend

cd frontend && npm install && npm run dev

Execute the bug reproduction:

• Open the application in browser
• Open browser console to observe network requests
• Click "Load Tags" button (observe loading state)
• Immediately click "Load Persons" button before Tags completes loading
• Observe that only Persons data appears in the UI
• Click "Load Tags" again - notice it makes a new network request instead of using cached data

@apollo/client version

3.13.8

[phryneas]

Could you please try our current Apollo Client 4.0 alpha and see if this problem persists?

Two things to keep in mind for 4.0:

• in 4.0, you need to import hooks and ApolloProvider from @apollo/client/react
• in 4.0, if you want to keep requests from useLazyQuery running after you start another one, you will need to call .retain() on the promise returned from calling the execute method

[TienThinh-fe]

Hi @phryneas,

Do we have the docs for trying the Apollo Client 4.0 alpha?

I got an error when update to 4.0 alpha version

import { ApolloClient, InMemoryCache } from '@apollo/client'
import { ApolloProvider } from '@apollo/client/react'

// Initialize Apollo Client
const client = new ApolloClient({
  link: 'http://localhost:4000',
  cache: new InMemoryCache(),
})

createRoot(document.getElementById('root')).render(
  <StrictMode>
    <ApolloProvider client={client}>
      <App />
    </ApolloProvider>
  </StrictMode>,
)

import { useLazyQuery, gql } from '@apollo/client/react'
import { useFilterContext } from './context/FilterContext.jsx'

[phryneas]

You'll need to pass a link into the link option:

const client = new ApolloClient({
  link: new HttpLink({url: 'http://localhost:4000/',})
  cache: new InMemoryCache(),
})

So far we only have the changelogs, we'll get to writing documentation on RC release.

https://github.com/apollographql/apollo-client/releases

This change was introduced in https://github.com/apollographql/apollo-client/releases/tag/v4.0.0-alpha.12

---

• #12589 15f5a1c Thanks @jerelmiller! - Require the link option when instantiating ApolloClient. This removes the uri, credentials and headers options from ApolloClient in favor of passing an instantiated HttpLink directly. To migrate:

  If using uri, credentials, or headers options

  new ApolloClient({
    // ...
  - uri,
  - credentials,
  - headers,
  + link: new HttpLink({ uri, credentials, headers }),
  // or if you prefer the function call approach:
  + link: createHttpLink({ uri, credentials, headers }),
  });

  If creating a client without the link option

  new ApolloClient({
    // ...
  + link: ApolloLink.empty()
  });

[TienThinh-fe]

Thanks for your information @phryneas.

Tries the version 4.0 alpha but got another critical issue: apollo/client gets the last cached value to the wrong request (different request variable but some how it still got the same cached value => incorrect data):

Screen.Recording.2025-06-17.at.18.58.20.mov

And the Apollo Client Devtools is broken on the new version:

ApolloError: Cannot destructure property 'document' of 'n.queryInfo' as it is undefined.

ApolloError
    at new t (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:354024)
    at chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:392228
    at i (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:361724)
    at chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:361638
    at new Promise (<anonymous>)
    at Object.then (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:361604)
    at Object.next (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:361734)
    at ft (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:274381)
    at ht (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:274894)
    at t.next (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/panel.js:1:275434)

[phryneas]

Yes, the DevTools will need to be updated for 4.0, we're not done with that yet.

---

As for your problem, I can see what's going on:

Your server returns all of those with the same __typename and id:

• { __typename: "Item", id: "1", name: "Nature", type: "tags" }
• { __typename: "Item", id: "1", name: "John Doe", type: "persons" }
• { __typename: "Item", id: "1", name: "New York", type: "locations" }

From the perspective of Apollo Client, all three of these are Item:1, will overwrite each other and can be used interchangably.

One option (and the one I recommend) is that you change your server in a way that it will never return __typename: "Item", id: "1" for different entities.

If that is not possible, you can specify a typePolicy to tell Apollo Client that these objects need more than just id to identify them:

const client = new ApolloClient({
  link: new HttpLink({ uri: "http://localhost:4000" }),
  cache: new InMemoryCache({
    typePolicies: {
      Item: {
        keyFields: ["id", "type"],
      },
    },
  }),
});

That way they will internally be identified as Item:{"id":"1","type":"locations"} etc. instead and not overwrite each other.

[TienThinh-fe]

Screen.Recording.2025-06-17.at.19.24.38.mov

Thanks @phryneas
Looks good with the typePolicies config. Does it need to move to version 4.0 alpha to get this behavior? Or we still can stay in the latest stable version?

[phryneas]

This has been the behavior of Apollo Client for about 5 years at this point, so you should be good with the latest 3.x.

[TienThinh-fe]

Hi @phryneas

I tried to use the version 3.8.8 (same as my current project using). And got this same behavior as I mention first time, the cache is only save the last one request => unnecessary re-fetching with the same variables

import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client'

// Initialize Apollo Client
const client = new ApolloClient({
  uri: 'http://localhost:4000/',
  cache: new InMemoryCache({
    typePolicies: {
      Item: {
        keyFields: ['id', 'type'],
      },
    },
  }),
})

Screen.Recording.2025-06-17.at.20.16.23.mov

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

[TienThinh-fe]

Click Completed by mistake, please help to open this ticket.

Thanks

[phryneas]

Please note that you are really abusing useLazyQuery here - the idea of useLazyQuery is to be a lazily initialized version of useQuery, which means that you start it later, but it still has the job of synchronizing your current UI with a singular hook call.

useQuery (and as such, useLazyQuery) isn't meant to hold three values at the same time or fire off a lot of unconnected requests - in that case, you'd have to call useQuery three times with different arguments to get three "instances" of useQuery.

Since you aren't using the "synchronize with a component" functionality at all, you can also call client.query instead, which has the purpose of making a query, writing the response to the cache, and giving you a promise for the result. I think this is a much better match for what you are trying to do.

[TienThinh-fe]

Yes @phryneas , I tried to implement useQueries three times and it works as expected.

Do I understand your point right with this summary:

• useQuery - When you want component synchronization for data that loads immediately
• useLazyQuery - When you want component synchronization for data that loads later (like search)
• client.query - When you DON'T need component synchronization (just cache the data)