You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fetch hangs when trying to access HTTP streaming API #12912
fetch() ... 0 ms
then() ... 32205 ms
catch() undefined is not an object (evaluating 'res.body.getReader') 32212 ms
i.e. where it doesn't complete until the server terminates the connection and when it does complete it saysres.body isn't an object. Whereas in Chrome it works as expected:
fetch() ... 0 ms
then() ... 28 ms
read() ... 28
Solution
It doesn't look like fetch has implemented streaming support which means we can't access long-running HTTP Streams in React Native.
We're cutting down on the number of outstanding issues, in order to allow us to focus. I'm closing this issue because it has been open for over 60 days with no activity. If you think it should still be opened let us know why. PRs are always welcome.
No kidding, so the new approach to resolving issues and reducing the issue count is to close down issues with small, stand-alone repros? Must be some new kind of approach to software quality control I missed the memo on. The reason why it should remain open is listed above in the issue, i.e. React Native can't access long-running HTTP Requests like SSE, except when debugging in Chrome where fetch (i.e. the primary method of communication) behaves as expected.
If reporting issues isn't considered valuable then I guess this is the last issue React Native I'm reporting, Congratz on your impending Issue Zero milestone, I'm sure you'll get there in no time!
A bug report with no comments on it for sixty days must not be blocking that many people. We're trying to cut down on the number of issues so we can better focus on what's currently affecting users.
I'm not saying that the bug is not worth fixing, but rather at this point if you're still blocked by this, it may well be worth looking into submitting a PR with a fix.
I'd be happy to leave this issue linger in the open state for another sixty days, though I am not sure that will solve your problem.
It's not blocking me because I can periodically poll and auto-reconnect but the end-user UX is noticeably worse because RN fetch can't handle long-running HTTP requests, I suspect other users would find their own way to workaround the issue given they still need to develop their Apps with whatever tools/API they have available but to dismiss this noncompliance and use-case as not an issue worth knowing about is IMHO a poor approach for maintaining a high-quality project.
Feel free to run your project as you like but I'd suggest using a label like up-for-grabs, low-priority or some other label that indicates the RN team wont be looking at it in the foreseeable future instead of just closing issues indiscriminately.
I'd be happy to leave this issue linger in the open state for another sixty days,
You're not doing me any favors by leaving the issue open, I thought I was doing you a favor by reporting an issue and submitting a small, stand-alone, verifiable example - but clearly the RN team doesn't view it as such so I'll be saving us both time and refraining from submitting any issues in future.
though I am not sure that will solve your problem.
This issue isn't my problem, it's React Native's problem with its W3C fetch implementation not functioning as expected. The other problem I see is how the RN team perceives the value of issues.
Reacted by RobIsHere, Médi-Rémi Hashim and Tamás Halasi
Will react-native ever supports SSE/EventSource?
Is there any plan to support SSE or not to include it?
IMHO the support of SSE would be really appreciated
Reacted by Alessio Igor Bogani, Tori Huang, Ho Yin (Michael) Cheng, Médi-Rémi Hashim, Demis Bellot and Rob Clouth
Activity
hramos commentedon May 25, 2017
We're cutting down on the number of outstanding issues, in order to allow us to focus. I'm closing this issue because it has been open for over 60 days with no activity. If you think it should still be opened let us know why. PRs are always welcome.
mythz commentedon May 25, 2017
No kidding, so the new approach to resolving issues and reducing the issue count is to close down issues with small, stand-alone repros? Must be some new kind of approach to software quality control I missed the memo on. The reason why it should remain open is listed above in the issue, i.e. React Native can't access long-running HTTP Requests like SSE, except when debugging in Chrome where
fetch(i.e. the primary method of communication) behaves as expected.If reporting issues isn't considered valuable then I guess this is the last issue React Native I'm reporting, Congratz on your impending Issue Zero milestone, I'm sure you'll get there in no time!
hramos commentedon May 26, 2017
A bug report with no comments on it for sixty days must not be blocking that many people. We're trying to cut down on the number of issues so we can better focus on what's currently affecting users.
I'm not saying that the bug is not worth fixing, but rather at this point if you're still blocked by this, it may well be worth looking into submitting a PR with a fix.
I'd be happy to leave this issue linger in the open state for another sixty days, though I am not sure that will solve your problem.
mythz commentedon May 26, 2017
It's not blocking me because I can periodically poll and auto-reconnect but the end-user UX is noticeably worse because RN fetch can't handle long-running HTTP requests, I suspect other users would find their own way to workaround the issue given they still need to develop their Apps with whatever tools/API they have available but to dismiss this noncompliance and use-case as not an issue worth knowing about is IMHO a poor approach for maintaining a high-quality project.
Feel free to run your project as you like but I'd suggest using a label like
up-for-grabs,low-priorityor some other label that indicates the RN team wont be looking at it in the foreseeable future instead of just closing issues indiscriminately.You're not doing me any favors by leaving the issue open, I thought I was doing you a favor by reporting an issue and submitting a small, stand-alone, verifiable example - but clearly the RN team doesn't view it as such so I'll be saving us both time and refraining from submitting any issues in future.
This issue isn't my problem, it's React Native's problem with its W3C fetch implementation not functioning as expected. The other problem I see is how the RN team perceives the value of issues.
luciozambon commentedon Oct 18, 2017
Will react-native ever supports SSE/EventSource?
Is there any plan to support SSE or not to include it?
IMHO the support of SSE would be really appreciated
abogani commentedon Oct 19, 2017
@mythz How have you worked around this limitation (I meant missing SSE support in react-native)? Thanks!
mythz commentedon Oct 19, 2017
@abogani no SSE behaviour in RN is fairly broken, ended up using really short heartbeat timeouts and put up with const reconnects.