So I have this strange error with React Native, where randomly network requests hangs.
This can be provoked by either listening to a remote audio file, or creating a new user and logging into the app.
This is an issue for all React Native versions at least over 0.59 (havent tested below that).
So to give a bit of background:
When I navigate to a new tab, I load data for that tab. Randomly it will just hang, and give a Network Request Failed with no further information. Once that arrives, and I navigate from and back to the screen it starts working again, until a couple minutes later where it will randomly hang one request.
Tried putting an aggressive timeout on it to provoke an early escape, but seems the native layer has to throw a Network Request Failed for it to start working again.
I've been biting nails for weeks trying to debug this issue, as it's limiting the release of the application.
Related
I'm very new to React Native and I'm understanding now Ports and similar things. In the last days I was able to access through Expo Go my app, but starting from today I ran into issues.
I think the problem was, that I was accessing the app using an university wi-fi connection, while the other days I used a mobile data connection. With Wi-Fi I was not able to access the app. The error log said: java.net.connectException: failed to connect to (...)
So I started a big journey thorugh ports, ip addresses and firewall, arriving to the ubuntu's ufw. Actually I don't know exactly what I've done, but the last try was to disable everything (like it was at the beginning) and retrying to access the app, nothing changed. The error log was: java.net.SocketTimoutException: failed to connect to (...) from (...)
I tried also use tunnel (like this question says Unable to connect to Expo React Native Project on WSL2 with Expo Go on phone) but it didn't help. In this case, the app says New update avalable: downloading... but never ends.
So, any suggestion to understand a) which is the real problem (a part that I've done something that I didn't understand) and b) how to solve it ?
When testing my React Native locally, I witnessed some strange behavior I am hoping to get clarification on
Context
I am building and testing a simple form that lets a user update their account info. If their new username is taken, the server responds with a 304 (otherwise, 200).
I am testing on my physical iOS device, and pointing my API against the local IP address that my expo cli is running from that is on the same wifi network (e.g. http://192.111.11.111:8080/)
Strange behavior
In every case where my local webserver does return a 304, my local expo app receives a 200. I have confirmed that my server is in fact returning a 304 with logging + breakpoints. Furthermore, when I point my API against my production server, which has the same backend code deployed, the app correctly receives a 304.
This leads me to believe that the only logical explanation is that there is some magic that expo does when doing local remote calls, but I have been unable to find anyone online that has had similar issues. Does anybody have any thoughts on what could be causing this?
We're facing an issue with handling unexpected behaviours when performing xmlHttpRequests on Android devices using React-Native. We've experienced behaviour where the app becomes unavailable to complete API calls, even though the device is connected to the internet perfectly well (browser can access non-cached sites just fine). The only way to resolve this issue for our users has been to completely restart the app.
To understand the issue and its severity, we wrapped all our API calls to a timer function in production and sent reports to Sentry whenever a request took longer than 30 seconds to finish. Now we've been receiving these kind of reports in the hundreds per day with the duration sometimes being in the hours or even days.
First, instead of using whatwg-fetch, we moved to using axios so that we can manually set the timeout of each request, but this ended up not helping at all.
Second, we dove deeper into understanding how React-Native actually implements timing out XHR requests on Android, and found that it uses OkHttp3 under the hood. OkHttp has a default value for connect, read and write timeouts and react-native allows developers to change the value of connect timeout here. However, OkHttp also has a method for setting a call timeout (everything from connect to reading the response body), but this has a default value of 0 (no timeout) and React-Native doesn't allow users to change that. More on okhttp timeouts here
My question is whether this can be the cause of our worries and whether it should be reported to React-Native as a bug. Lets assume the following case:
app makes an API call to a resource
okhttp is able to connect to the resource within specified timeout limit (default 10s)
okhttp is able to write the request body to the server within timeout limit (10s)
server processes request but for some reason it fails to start sending a response to the client. I guess there could be many reasons for this like server being disconnected, server crashing or server simply losing the connection to the client without the client noticing it. As there is no timeout here, okhttp will happily wait for days on end for the server to start responding to the request.
Am I missing something here or misunderstanding how timeouts work in okhttp? Is there another, perhaps better solution than implementing the ability for developers to set callTimeout on API calls performed on android? And also, isn't it a bit stupid that developers cant set their own write and read timeouts? Cant this lead to unexpected behaviour when you want to send large amounts of data in either direction on a slow connection? 10s is quite long, but perhaps not long enough for all use-cases.
Thanks for your help in advance!
I'm working on a React Native app, testing in an android emulator. I've used the standalone React Native Debugger app as well as the debugger that opens in Chrome. In the Chrome window, the Network tab shows no activity, so that's no help. In the standalone debugger, the same is true until you right-click and choose Enable Network Inspect. The problem I'm having is that after I enable network inspecting in the debugger, all network requests fail - the inspector shows their status going from Pending to Canceled after a few seconds. I can see in my server logs that no requests are coming in. It's like debugger itself is somehow blocking the requests.
I've set up adb to run as root. When I run react-native run-android the output includes Running adb -s emulator-5554 reverse tcp:8081 tcp:8081, so I think things are starting up fine. The network requests from the app (login etc.) work fine (a typical URL would be http://10.0.2.2:2080/api/LoginScreenController/GetIdentityStatus), until I choose "enable network inspect" in the debugger, at which point all network requests fail as described above.
Any suggestions would be appreciated.
I know that I'm too late but perhaps it will save time for somebody.
During the update of the react-native, I did update the version of the react-native-reanimated from v1 => v2, and after it, I faced the same behavior.
Version 2 requires to enable Hermes engine if it won't be enabled then all the requests will be in pending status
To simplify my problem: I have an ecommerce app that uses geofencing to detect when to prepare an order:
BackgroundGeolocation.onGeofence(geofence => {
this.props.prepareOrder();
});
The thing is, prepareOrder() makes an HTTP request to my server. I've noticed that it doesn't actually make the request until my app is foregrounded.
Is there a way around this? It is very likely that my app is backgrounded when they enter the geofence and I need to make a request.
======
The more complex version is here: https://github.com/redux-saga/redux-saga/issues/816. I'm using redux-sagas and it doesn't seem like yield call is being called. But I'm not sure if it's a redux-saga thing or something with making HTTP requests in the background.
Same here... It's not a redux-saga problem, it's a more general problem with ReactNative apps working in background: the JS Thread appears to be frozen when app is in background for a long time (especially on iOS when screen is shut down)
the behavior is different between iOS & android, and also depends on OS version. Still, We're building an application that needs constant geolocation in foreground & background, we tried doing it with sagas and we saw it didn't work : we would stop receiving locations after some time. Watching at our logs, we would see that all the ReactNative logs we had would stop too. Hence our wild guess on "maybe the OS stops all the ReactNative context, for energy reasons
So we moved our background code into native :
HTTP POST in a custom RN Native Module when app is in background on iOS
Headless JS on android.
(it seems to be the solution others have chosen too, like https://github.com/mauron85/react-native-background-geolocation)
it works!