cc @martinbigio we were talking about this

Do sourcemaps in redbox work for you on Android when you're connected to the debugger?

Now that you mention it, nope, sourcemaps in redbox are not working when connected to the debugger.

Got the same problem on linux with the v0.22 as well. Interacting with the debug menu breaks the logjam.

For me, sourcemaps stop working after a while and I start seeing the transpiled code. That is happening when this error is occurring. But the problem also happens after a reboot before the sourcemaps stop working.

From Stackoverflow: http://stackoverflow.com/questions/36262456/what-could-be-causing-this-slow-fetch-in-react-native

In the following code, the first console.log message prints pretty much instantly. Then everything just hangs (I'm initially assumed it was waiting for the body of the response to be returned). The Body of the response is only about 26K, the time waiting seems to be indefinite UNLESS, I shake the phone and interact with the debug menu. * As soon as I interact with the debug menu, the promise resolves and everything moves along as expected.* My interactions with the debug menu can be simple, like hide inspector, show inspector, just takes something to kick the promise resolution into gear and everything is fine.

    fetch(SEARCH_URL, requestBody)
        .then((response) => {console.log(response); return response.json();})
        .then((responseData) => {
            debugger
            ...

Note:
Disconnecting from the debugger and running the code does not exhibit the slowness (and not being connected to the debugger ignores the debugger statements)

And yes, I have rebooted the computer.

@steveluscher you were looking into setTimeout issues. Could this be related?

@cpojer, @skevy have we recently made any change to the Promise implementation?

cc @bestander, @vjeux

I've been seeing ‘setTimeout never fires’ behavior intermittently as well, with timeouts > 0ms. The only clue that I had was that my Genymotion simulator clock and my system clock seem to drift apart over time. I didn't try opening the debug menu when stuck, nor have I noticed this on device yet (I haven't done anything on device in a while). That you've experienced the same behavior on device as you have in Genymotion makes me think it's not going to prove to be clock drift between the host running Chrome and the host running the app.

Takes more than opening the menu, you have to choose something from it, like hide/show inspector. I'm not using a simulator.

I'm having the same issue on an S4 mini, except I can stop the behaviour by tapping the screen without opening the debug menu.

Got same issue with response.text(), response.json() and response.arrayBuffer(), but response.blob() seems to work fine. Versions are:

react-native-cli: 0.2.0
react-native: 0.22.2
Android 5.1.1

Quick workaround is to add empty timeout execution:

fetch('http://example.com')
    .then(response => {
        setTimeout(() => null, 0);
        return response.text();
    })
    .then(response => {
        console.log(response);
    });

I can confirm just tapping anywhere on the screen does work around this problem.

Do we know when this regression started repro-ing? Do you guys mind sharing which version of react-native you're using? I want to make sure this is not a regression of the current RC.

cc @bestander

It was in a version installed from npm on March 24. I don't know the version at the moment, but I can look it up tonight.

I have the same problem with 0.22 and iOS on my mac (installed 1 hour ago).

Tapping anywhere + the setTimeOut workaround does not work for me.

So this may have been introduced on 0.22, so not 0.23 launch blocker though we should fix asap.

This is due to our incomplete XHR2 implementation. Check this code that was added with cbc0e21.

Please consult the spec before fixing stuff.

Should this be fixed in 0.24? The problem persists for me with 0.24

No, this is in 0.25-rc

Is it fixed in v0.25.0-rc? Because it persists there as well...

Actually the commit is supposed to be in 0.24.1, it has been cherry-picked into the branch https://github.com/facebook/react-native/commits/0.24-stable.
If you still reproduce the bug then the fix does not work.
cc @davidaurelio

yes - I still reproduce the error with 0.24.1 - Am I supposed to to do any changes to my code? I have not changed it since it broke around 0.22.

It seems something is off with the sourcemap, the one from my bundle has multiple sections but it seems that when we parse it we expect to be flat https://github.com/facebook/react-native/blob/master/Libraries/JavaScriptAppEngine/Initialization/SourceMap.js#L1086
The sourcemap I get using the explorer is flat:

But the one I get from my project has sections:

The promise is rejected, it seems that SourceMap does not handle sections, I updated it and got the Stacktrace in the red screen working fine after commenting in parseErrorStack, but this didn't fixed the freezing issue of the Chrome Debugger.

// if (frame.file.indexOf(sourceMap.file) !== -1 ||
//     frame.file.replace('.map', '.bundle').indexOf(
//       sourceMap.file
//     ) !== -1) {
  resolveSourceMaps(sourceMap, frame);
// }

@jrichardlai oh yes, that’s a super old version of the source map library. Using what we have in node_modules should do the trick. PR welcome. Will look into the other issue now.

i have same problem to, i use 0.25.1 and fetch problem not resolve for now. i think fetch is important part to use web service in mobile app and need to fix.
for now i just use version 0.19
my issue same with #7381

Any update on this issue? Possible workarounds besides just tapping on the screen.

react-native-cli: 0.2.0
react-native: 0.25.1
Android: 5.1.1

Looking for an update. I have upgraded to:

react-native-cli: 0.2.0
react-native: 0.26.0
The problem still occured.

Having this issue as well. Very frustrating.

How does one debug React Native apps that fetch JSON? 😭 @lacker can you please re-open as this is again an issue

@danawoodman debug? Well make log lines everywhere to the console And see where iT reaches like for Every line a console.log("1"); And count up And see which logs arent found And you Got the issue where Its stuck. Use above workarounds to fix it. As there is No generaal fix for this issue.

This error still exists RN 45.1

@cablegunmaster yes, what I am saying is that without a hack you cannot troubleshoot your apps since the debugger causes this issue to fail with fetch.

I was also pulling my hair over this. Glad I've found this issue!

Didn't encounter this issue before, but once i upgrade from 0.44.0 to 0.46.0 today it pops up. The response.json() is just stuck, doesn't invoke then() nor catch(). Like some said, the fetch() was called from a helper function defined outside of a React component, but is called by a react component.

Encounter this issue sometimes only through React Native versions 0.44, 0.45 & 0.46. What would I do without these updated issues on Github and user submitted work around? 👍

Yay, this appears to be fixed in 0.47 by 6482538 !

I too had faced same issue while debugging on ios Emulator with react-native version: "0.46.4". But as @mikelambert suggested, upgrading to version "^0.47.0-rc.5" solved this issue

but it still hangs on android devices.

i'm still seeing fetch on android devices being really slow. i'm on 0.49

of course, why didn't i think of that

Just a reminder @mark0978 and @chug2k , this is fixed in the latest version of RN 0.47.

@mikelambert nah... Fixed only for ios, android still broken.

@reactjs-bot @mikelambert I am still following this post as it seems for me just a stupid bug which should be squashed ages ago, but nobody has/takes the time to do so. #android

wtf i spent 12 hours trying to adjust my code, wondering why it wont go within a .then statement of a promise only to find out its a freakin bug

you can always make your own pull request to address the issue

wtf i spent 12 hours trying to adjust my code, wondering why it wont go within a .then statement of a promise only to find out its a freakin bug

same here!

@maxim-c @mikelambert , if this is only fixed for iOS, shouldn't this issue still be open for Android devs? Reading the entire issue, it seems prematurely closed by @lacker , am I wrong?

Its not fixed on Android, just some nasty work arounds. ( tapping on the screen kind of )
Which you don't want the user to do in order to go further.

This actually still happens on Android, and when using an emulator even tapping the screen doesn't help..