As of 3.5.0 a mutation's onCompleted that references data from a query that is updated has stale references

[charle692]

Intended outcome:
Whenever a mutation's onCompleted references data from a query, that onCompleted has stale data references in the case where the mutation causes the query to update.

Actual outcome:
Whenever the mutation's onCompleted is invoked, it has the updated reference to the query's data property.

How to reproduce the issue:
I've created a super simple reproduction here with a test case, just run:

• npm install
• npm test

I've also included a branch where the only difference is that @apollo/client version 3.4.17 is used and the same spec passes properly.

NOTE: I didn't see the template until my reproduction was created, my reproduction is super simple and contains a test to demonstrate when it's working properly. Hopefully that's ok.

Versions

  System:
    OS: macOS 12.2.1
  Binaries:
    Node: 14.18.2 - ~/.nvm/versions/node/v14.18.2/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 6.14.15 - ~/.nvm/versions/node/v14.18.2/bin/npm
  Browsers:
    Chrome: 96.0.4664.55
    Safari: 15.3
  npmPackages:
    @apollo/client: 3.5.10 => 3.5.10 
    apollo-upload-client: 17.0.0 => 17.0.0

Working Versions

 System:
    OS: macOS 12.2.1
  Binaries:
    Node: 14.18.2 - ~/.nvm/versions/node/v14.18.2/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 6.14.15 - ~/.nvm/versions/node/v14.18.2/bin/npm
  Browsers:
    Chrome: 96.0.4664.55
    Safari: 15.3
  npmPackages:
    @apollo/client: 3.4.17 => 3.4.17 
    apollo-upload-client: 17.0.0 => 17.0.0 

[charle692]

This seems similar to #9111 but might not be exactly the same.

[whytspace]

could this be realted to #9333?

[charle692]

could this be realted to #9333?

No I don't believe it's related. That issue seems to be that the data coming from the query is delayed? Vs in my case the query data is as it should be but whenever you access that data specifically inside a mutation's onCompleted callback, the reference is stale.

In the reproduction it's clear that the query is operating properly :). I'll circle back to this and post the output of the reproduction and that should illustrate things.

[charle692]

Just circling back to say that I've tested this against the latest 3.6.0-rc.1 and it has not been solved. @benjamn any chance that this can be looked at?

We haven't been able to upgrade since 3.5.0 really don't mind taking a look either but might need some guidance on where to look first.