Apollo-client: "Out of stack space" error

[lehresman]

Intended outcome:

In our application, we are using Apollo Client, and are doing some manual queries (i.e. not attached to a component). I would expect that it works on IE11 like it works everywhere else.

Actual outcome:

On IE11, we get an "Out of stack space" error thrown in IE11. This only happens when we make Apollo Client queries. When we comment out our graphql queries, our application works fine on IE11.

The weird thing is this error only occurs when Google Maps is included. When we remove Google Maps, everything works great. ... I know, right?!

How to reproduce the issue:

I have boiled it down to a small reproducible example. To reproduce:

git clone https://github.com/lehresman/apollo-client-ie11-example.git
cd apollo-client-ie11-example
yarn install
node server.js

Then visit http://localhost:3001 in IE11

Edit www/index.html and remove the Google Maps <script> tag and you'll see everything works fine.

Version

• [email protected]

[valstu]

Having exactly the same issue here, it only appears with Google Maps included. Everything got fixed when I added few core-js polyfills:

import 'core-js/modules/es6.typed.uint8-clamped-array';
import 'core-js/modules/es6.weak-map';

But on another project with similar stack the issue persisted even when I added those polyfills.

[valstu]

I made an example repo today for debugging with create-react-app which is just making simple GraphQL query. If I have the Google Maps script tag in index.html I'll get the out of stack trace error, If I remove it the error is gone. I tried the other way as well, removed all the Apollo related stuff and kept the Google Maps script, nothing, no errors.

Another thing I noticed was that if I made a production build of my simple app you won't get the error.

Here's the link to my repo
https://github.com/valstu/apollo-client-ie11-bug
Just clone it and install dependencies with yarn or npm and run yarn start. Open the site with IE11 and you'll get the error.

[petetnt]

We looked through the issue with @valstu and the issue is there seems to be rather complex (or at least sounds silly, but hear me out 😂):

The failing piece of code is

https://github.com/apollographql/apollo-client/blob/6eec674f206cda11cf667a89022354b1476f5503/packages/apollo-client/src/core/QueryManager.ts#L588-L596

which calls deepFreeze similar to substack/deep-freeze in apollo-utilities:

https://github.com/apollographql/apollo-client/blob/a32f31d79806a29cd2a9f6211d64c92997d5408a/packages/apollo-utilities/src/util/maybeDeepFreeze.ts#L3-L18

Okay, now the silly part: when Google updated Google Maps to version 3.30 I'd assume they updated their version of Closure Compiler too. The reason why everything fails is that Object.getOwnPropertyNames(o) suddenly has the Symbol polyfill keys in them:

(jscomp_symbol is the Symbol polyfill of Closure Compiler, right?)

... which ends up in endless loop on IE11 and eventually crashes the browser. I'd think the issue might be related to https://github.com/google/closure-compiler/issues/2448

Using different deepFreeze doesn't help either, we tried deep-freeze-strict and js-flock first to check if some other deepFreeze implementation wouldn't have the same problem but obviously enumerating the ownProperties rely on the same things.

(Downgrading to Google Maps v3.29 isn't an option either anymore as they retired it, so there's that too.).

I don't know if there's any other short term solution to not deepFreeze them, but that has its own downsides. On the other hand this should only occur on non-production version IE11, which only affect one if they are trying to debug Google Maps issues on IE11 (like we have done for like 5 working days now...).

Also: https://twitter.com/pete_tnt/status/940987922664312832

[lehresman]

Wow that's crazy, but it makes sense! Good sleuthing!

[petetnt]

Another short term solution could be whitelisting the properties that should be freezed

[valstu]

Yeah I guess Google isn’t going to do anything.

[petetnt]

Workaround pending in #3082

[owenkim]

@petetnt Big thank you for the clarity. I spent all of yesterday digging in and only got as far as figuring that hasOwnProperty was part of the circular reference. Importing the core-js polyfill before sourcing Google Maps seems to have fixed my issue.

Can you clarify what you mean by "On the other hand this should only occur on non-production version IE11"? I bumped into this in my production builds and standard releases of IE, reproduced with the Win8, IE11 VM Microsoft hands out here.

[petetnt]

@owenkim I had assumed that it would only happen during deepFreezing which would only occur in test and development enviroments but looking through the code I have to check if the issue occurs on for in... calls too (and others where hasOwnProperty is called part of a recursive call as a check like in https://github.com/apollographql/apollo-client/blob/9b0a587b9d5d94016d6fcb27db8d6e8d0ae1ff93/packages/apollo-utilities/src/util/cloneDeep.ts#L13-L17.)

[petetnt]

If it is, cloneDeep is called in non-test environments by at least apollo-link-state via removeClientSetsFromDocument

https://github.com/apollographql/apollo-link-state/blob/2b38eb898ad853c7bd0ca70801a9548a2e7c3df3/packages/apollo-link-state/src/index.ts#L63

which calls removeDirectivesFromDocument which eventually calls cloneDeep.

[petetnt]

Okay, double checked that and at for in... calls don't seem to end up in endless loops due to it only enumerable properties which the polyfilled Symbols are not.

[petetnt]

Workaround was merged just now 👍

[hwillson]

Fixed by https://github.com/apollographql/apollo-client/pull/3082 (thanks @petetnt!).