fetch has weird behavior for 0.45.1 when debugger is attached

Description

I’ve upgraded one of our apps to 0.45.1 (from 0.42.3) and fetch has some weird behaviour when attaching the Chrome debugger. The Promise with the Response returns as normally. What is weird is if I try to return any of the Promises from the Response, e.g. response.text(), then I must touch/click the UI in order for it to continue.

For example, this works fine:

fetch('https://github.com/facebook/react-native')
  .then((res) => console.log(res));

It will log the Response-object when the GET completes. But if I add another then to return for example the text of the response:

fetch('https://github.com/facebook/react-native')
  .then((res) => res.text())
  .then((text) => {
    console.log(text)
  });

Then I must touch/click the UI in order for it to run the last then.

If I set a break point into the function which handles the console.log, I even see from the call-stack that it is callFunctionReturnFlushedQueue with the touch-event as scope variables which triggers the Promise resolution:

Reproduction Steps

1. Download the below sample project. Important file is Core.js.
2. Run the app. Note that the UI quickly goes from “Not done” -> “Done 😄”
3. Attach debugger, reload app. Note that it stays on “Not done”.
4. Click the UI, it should go to “Done 😄”.

Sample Code

Sample project here.

Additional Information

• React Native version: 0.45.1
• Platform: Both
• Development Operating System: macOS
• Build tools: Both iOS/Android.

[cbrevik]

So, I have a bit stronger suspicion that it is “sleep” related.

If you debug the app in Xcode, and set a break point in createTimer (used by setTimeout, setInterval, etc) using RN 0.45.1, if you do do not have the debugger attached, then it will break into that method and create a new timer every two seconds.

While if you have the Chrome debugger attached, it will only break into it a couple of times and then stop.

Testing the same code with RN 0.44.3, it always break into the method every two seconds, regardless if the debugger is attached or not.

Turns out createTimer is in this case called from setTimeout, which has the following stack trace:

Drilling into the arguments at the bottom of the stack I find:

websocketFailed in turn seems to be related to RCTWebSocket connection failing. Which is called here. If you set a break point into that method you see the same behaviour. It will break into it every two seconds, except for RN 0.45.1 with Chrome debugger attached.

Wondering if it might be related to #10027, and any fixes done there? That issue thread is a bit sparse on info though.

Or, I might be completely wrong here. It makes no sense that some random timer polling WebSocket-connections should keep the rest alive when debugging. But that’s as far as I’ve gotten thus far.

[cbrevik]

@mikelambert I read that comment but it seemed (at first glance) like the fix was Android-specific?

@javache Thanks! Did a simple test with 0.47.0-rc.1, seems like that commit fixed it. Closing this issue.