-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
response.text() and response.json() get "stuck" sometimes #14391
Comments
Seeing this as well. Commenting to bump. |
Same here. It seems this only happens in React Native 0.45. For me the probability is around 50%. Quick workaround: Tap the screen to continue. |
I also experienced this behavior after upgrading to 0.45. |
Just upgraded and ran into this bug. Using @sebandres' quick hack to force it to complete.
|
And the modified ES7 form of the above code that also works for me (thanks!):
Just add the setTimeout before you call As far as the underlying bug, definitely feels like the eventloop "falls asleep" when processing |
And I just found this comment (in a "closed" bug), which might describe the root cause of this issue: #9436 (comment) |
Yay, this appears to be fixed in 0.47 by 6482538 ! |
thanks @EdwardHuCS |
My code more or less does the following, on React Native 0.45:
When running this in Chrome Debugger on the iOS Simulator, the result will get "stuck" sometimes. By that, I mean the first time I call it, it works fine. But the second time I run a request, the
data
will not be printed out until something else happens to jiggle the event loop and cause it to return.If I disable the chrome debugger, things work.
I assume this is related to what people have been complaining about on the prematurely-closed bug #6679 .
=================
What follows is my attempt at debugging. I won't promise anything, as I'm not a promise expert, but maybe it helps narrow things down?
The http response data is shuffled into the
response.blob
. Whentext()
orjson()
is called, it callsreadBlobAsText
to read the blob, and I do see the string successfully loaded and passed around within thepromise/setimmediate/core.js
code. Unfortunately, this string doesn't always make it back to the caller for some reason.(This might be a red herring, but I see it call
handleResolved()
and the equivalent ofsetImmediate((self, deferred) => tryCallOne(deferred.onFulfilled, self._65 /* body payload */))
, but the anonymous function isn't actually called immediately...)And interesting to note, if I edit
fetch.js
to disablesupport.blob
, it also works.This makes me suspect it has something to do with the
text()
function. In most cases, it returnsPromise.reject
orPromise.resolve
, but in the case of using blobs, it returns a newly-generatedPromise
(from thefileReaderReady
function). My guess is that this probably triggers another level of promise-indirection, that somehow causes it to stall before the event-loop notices it and triggers it to complete.I'm still quite a newb as to the
JSTimers*
code and guts of thepromise
code, so this is where the trail goes cold for me. :(The text was updated successfully, but these errors were encountered: