-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maximum call stack size exceeded possible in query with object queried at multiple graphql paths #4081
Comments
Can you put together a CodeSandbox reproduction? We shouldn't be returning the same |
Here's a simple reproduction: https://codesandbox.io/s/94w34wx1ow I also quickly tried creating a test only for apollo-cache-inmemory but for some reason I couldn't get the problem to occur while only testing |
As #4081 demonstrates, if there are key collisions during result merging, it's possible for source objects that were previously merged by reference into the target object (finalResult.result) to be modified destructively by later merges, which in some cases can lead to cycles in the results returned by the cache. This version of the merge function uses a copy-on-first-write strategy to ensure we never modify target objects that might once have been source objects. The code could have been considerably simpler if I didn't try to track pastCopies, but performance and memory usage are very important for this code, which is why I went to the trouble of limiting the number of shallow copies made during a single merge.
@abergenw I believe I've tracked this bug down to the |
I can confirm that |
Since |
I have a query somewhat with the following structure:
If the same company (same id) is returned both under
authenticatedUser > company
andauthenticatedUser > company > users > company
, it seems like the same object instance is returned from apollo-cache-inmemory. This has all sorts of implications, not least as it can lead to the resulting object having a cyclic nature making Apollo cause a RangeError when usingisEqual
.I suspect this is because in the above example the company selection set is cached (with users) and thus not evaluated correctly for
authenticatedUser > company > users > company
(without users). Maybe @benjamn can confirm this?Versions
System:
OS: macOS High Sierra 10.13.6
Binaries:
Node: 8.11.4 - /usr/local/bin/node
Yarn: 1.10.1 - /usr/local/bin/yarn
npm: 5.6.0 - /usr/local/bin/npm
Browsers:
Chrome: 70.0.3538.77
Safari: 12.0
npmPackages:
apollo-cache-inmemory: 1.3.7 => 1.3.7
apollo-client: 2.4.5 => 2.4.5
apollo-link-batch-http: 1.2.3 => 1.2.3
react-apollo: 2.2.4 => 2.2.4
npmGlobalPackages:
apollo-codegen: 0.10.5
The text was updated successfully, but these errors were encountered: