RN fetch fails after successfully connecting and disconnecting with wifi
See original GitHub issueHey,
I’ve experienced a weird issue that I narrowed down to this library. I am using a Samsung A40 with Android 10, RN 0.63.2 and version 4.3.3 of react-native-wifi-reborn.
In my app, I connect to a wifi provided by a sensor (a seismograph to be more specific) which is not connected to the internet, retrieve its measurements with fetch requests and then disconnect from its wifi again. This procedure is repeated over and over during a field day. In between measurements, the app uses mobile data to upload the measurements to a server (that is the reason for connecting and disconnecting again). As soon as mobile data is turned off briefly or the connection is lost and reestablished, all future fetch requests to the server fail with the below error message (which unfortunately provides no helpful information for me). Requests to the sensor when connected to its wifi still work. After shutting down and restarting the app, the fetch requests work again.
TypeError: Network request failed
at C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\whatwg-fetch\dist\fetch.umd.js:527
at C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\Core\Timers\JSTimers.js:235
at _callTimer (C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\Core\Timers\JSTimers.js:130)
at Object.callTimers (C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\Core\Timers\JSTimers.js:383)
at MessageQueue.__callFunction (C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:416)
at C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:109
at MessageQueue.__guard (C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:364)
at MessageQueue.callFunctionReturnFlushedQueue (C:\Users\msteinbrink\WebstormProjects\seismic\node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:108)
at debuggerWorker.cff11639.js:4
The data with headers to be uploaded when a fetch request fails was tested in Postman and worked without a problem. After disconnecting from the sensor’s wifi, the WifiManager.connectionStatus() method returns false and NetInfo also shows the connection as connected to the internet via cellular.
I also removed this package’s dependency and tested the same workflow with manually connecting and disconnecting the wifi in which case future fetch requests work as expected. When using this package and briefly disconnecting mobile data without polling a sensor meanwhile, future fetch requests also work as expected. Only if mobile data is briefly disconnected and this package is used to connect and disconnect from the sensor’s network, future fetch requests to the server always fail until the app is restarted.
Therefore, I suspect that using the WifiManager to connect and disconnect to the wifi without internet somehow breaks future fetch requests. Do you have any idea what could cause this problem and why restarting the app resets it?
I don’t know if it is relevant, but fetch requests to the sensor are http and not https (like the requests to the server). Therefore, android:usesCleartextTraffic="true"
was added to the AndroidManifest.xml.
Any help would be greatly appreciated!
Issue Analytics
- State:
- Created 3 years ago
- Comments:18
@eliaslecomte I just tried it with your advice and it worked! Thank you and @Rapsssito for your help.
I added the following after connecting to the sensor’s wifi on Android:
And this after disconnecting from the sensor:
Hey @MarcoStb1993. Are you using forceWifiUsage or forceWifiUsageWithOptions? It’s importantant to unforce it after executing your api call to the device:
await forceWifiUsageWithOptions(false, { noInternet: true });
If you wouldn’t, the app can only use wifi, but it’s no longer connected to the wifi. Other apps or the os are also not able to use the mobile data. The situation would be resolved when you call forceWifi or actually kill the app.