Promise neither resolved nor rejected in IE 11

[deepfriedbrain]

I have an application hosted on Google App Engine using Google Cloud Endpoints 1.0. The frontend is React based and using Google Javascript Client API to make calls to the Endpoints APIs. I'm using babel-polyfill. Everything has been working fine on modern browsers (Chrome, FF, Safari, Edge).

But recently I found that some of the Google API calls to my endpoints on IE 11 were neither getting resolved nor rejected. After further investigation, I found that if response payload was small (1-2KB) enough, the API calls would get resolved. But if the payload is even slightly (5KB+), the call would neither resolve nor reject for the very same API that worked with a small response payload. Basically, any API that returns a small payload works, and any that returns slightly larger payload fails.

It used to work correctly when I last tested it around Feb this year. My application has been stable for the past few months and I've not made any major changes.

In the IE 11 Dev console, I can see that the request is successful with the response code 200, and all the data is coming back in the response body without any issue. But the promise is not resolved even when the request is successful. Most requests usually complete within 2 secs.

Since the exact same code works if the response payload is small, the issue is unlikely to be related to the code (I can safely say it is not a polyfill issue). I have spent several hours debugging the issue and really out of ideas now.

Any help or ideas would be really appreciated.

Here's the stub for my API call:

gapi.client.myendpoint.getData({param}))
    .then(resp => {
        // process response
    }
}, resp => {
    // handle error
});

[bsittler]

@deepfriedbrain Is it possible to learn more about the failing API call or its response data? Is the response JSON or some other format? In IE11 I am able to successfully call the following API with a 20451-byte result:

gapi.client.request('https://www.googleapis.com/discovery/v1/apis/discovery/v1/rest').then(
    function (resp) {
        console.log(resp.result.kind, resp.body.length);
    });

Console output:
discovery#restDescription 20451
Does that call work on your test page? Does it work in your IE11 instance with the gapi.client but no other scripts?

[deepfriedbrain]

@bsittler Thanks for your response. The call you provided worked successfully in my application (Staging version) with the same IE 11 setup and I got the same output discovery#restDescription 20451 as you did.

My response data is in JSON format. If you are fine, I can email you the links to both production and staging versions (containing the above discovery API call) of my application and you can login using your Google account and try it for yourself.

[bsittler]

First, can you attempt to make the same API call to your API from a web page with no other library or framework scripts except gapi.client? And is the call to your API made via GET or POST or some other HTTP request method? Finally, if the data itself is not sensitive could you share the response payload here? (If it is sensitive, no problem -- I'm just trying to get an understanding of the shape of the JSON)

[deepfriedbrain]

I found the root cause and fixed it. There was a \u in the JSON response that was tripping IE 11, though it was working fine on other browsers. Even though Cloud Endpoints seemed to be escaping it like so - \\u - IE still didn't like it. It was a huge payload and took a while to isolate the problem.

I really appreciate your help. It was due to your pointers that I scrutinized the content more closely. Thank you so much!

I'll close the issue.

[bsittler]

@deepfriedbrain glad you found it! However, that still sounds like a browser-specific bug in gapi.client. Are you able to paste a short example where the unsupported gadgets.json.parse(' "some string \\u etc" ') returns false in IE 11 but works in other browsers?

[deepfriedbrain]

I'm not clear about what you are asking me to try (and not familiar with the Gadgets API). But I could reproduce the problem with a very simple JSON response such as this:

[
   {
      "key": "\\u"
   }
]

The original string though contains just \u, but the Endpoints API adds the escape character to make it \\u.

[bsittler]

Thanks @deepfriedbrain - I'll do some further investigation and post updates here as they happen

[bsittler]

This should work now. @deepfriedbrain can you verify that it now behaves correctly with the same data that previously exposed a library bug in IE?

[deepfriedbrain]

Hello @bsittler I have tested it and it seems to work fine now. I'll remove my workaround. Thanks a lot for your help.

[bsittler]

Thanks for the confirmation, @deepfriedbrain - and also for reporting the issue so promptly to start with and for your assistance with narrowing down the cause