react-native-netinfo: Netinfo showing wrong status when both wifi and cellular data are active

I don’t personally have maintainer power here. @matt-oakes ? I’ve never seen anyone else commit. Note that even were I to have maintainer power here to merge something: someone needs to make a PR. This is open source. Don’t just sit there and “me too” issues, roll up your sleeves and do work, that’s how it moves forward.

i have the same issue !!!

if you are not a native mobile developer

What exactly is a native mobile developer? Ask yourself that, then perhaps change your perspective. You have all the tools installed. You are a developer (not a ___ developer), and to fix things just needs a developer (not a ____ developer).

Try things. Experiment. Play around. Learn. Find the problems, fix the problems. That’s just what developers do.

We can only rely on the community and hope someday it’s going to work again.

You are the community, and hope is not a plan. Open up the code in the related tools and try things.

@umerqr It’s a big pain to work with react-native if you are not a native mobile developer. We can only rely on the community and hope someday it’s going to work again.

@gnprice there is new activity in this area from @Willham12 in PR #510 - if you have a minute can you please examine that PR, it may be better than the strict revert of #443 by nature of actually removing state and just querying things fresh on events, returning all fresh info. I’d love to know what you think

I’m experiencing the same issue. I can reproduce this on my Android-device by

1. Run app while online
2. Turn on airplane-mode
3. (internet reachable false)
4. Turn off airplane-mode
5. (internet reachable true)
6. Wait ~ 20 seconds
7. (internet reachable false)

After step 4, if I try to turn on airplane-mode again, it doesn’t report any state-change so I don’t get notified that the device is offline.

I debugged natively on Android and it looks like it is the Android-part that reports “onLost” when I see the “internet reachable false” in step 5.

Maybe this is relevant: https://gist.github.com/PasanBhanu/730a32a9eeb180ec2950c172d54bb06a.

Edit: Pixel 4, Android 12. RN 0.64.2, NetInfo 6.0.2.

I’m randomly observing a similar issue on Android 9, although may also happen with Android 11, still trying to reproduce.

Turning on/off the WiFi while having a data connection may randomly end up reporting no connection. This started happening after upgrading to RN 0.65 and Android SDK 31. Still trying to reproduce.

That’s a good analysis. The critical part is I think this:

In particular I think this means that the code as it currently is will work unreliably even for the motivating use case of #443: if the app-specific wifi network becomes available, but then some other network goes away, we’ll stop thinking there’s a connection at all.

If the change that caused the breakage is not even reliable, then that’s a strong case for revert. Obviously I’d love to see the slightly-more-network-aware/stateful version of 443 implemented but I don’t have the time myself.

Any dissent from 443 revert then? I’ll consider it a sort of “call for comments”. I’ll let it sit for a day or two. Obviously you may revert locally via patch-package in the meantime. If there’s some well-reasoned dissent I/we can hold off. Otherwise if there is no dissent in the next couple days I’ll revert and release.

Thanks very much for thinking through it @gnprice

I’m seeing these symptoms, reproducible with the steps in https://github.com/react-native-netinfo/react-native-netinfo/issues/481#issuecomment-938505186 , after an upgrade from 6.0.0 to 6.0.2.

I took a look at the code in NetworkCallbackConnectivityReceiver, and I think I see what the bug is. Here’s the callback we pass to registerNetworkCallback:

    private class ConnectivityNetworkCallback extends ConnectivityManager.NetworkCallback {
        @Override
        public void onAvailable(Network network) {
            mNetwork = network;
            mNetworkCapabilities = getConnectivityManager().getNetworkCapabilities(network);
            updateAndSend();
        }
        // …

        @Override
        public void onLost(Network network) {
            mNetwork = null;
            mNetworkCapabilities = null;
            updateAndSend();
        }
        // …

When the system invokes one of our callback methods, it passes a particular network that there’s an update on. But then we’re tracking the state of only one network at a time; so whatever network we just had an update on, we remember that and forget whatever we knew about any other network.

Before #443, this worked consistently: the callback was only subscribed to be invoked on a single network at a time, namely the default network. That was a limitation that would be good to fix (which was the motivation for #443); but the code did provide an accurate picture of the state of that one network, which is good enough for many use cases.

After #443, though, the code doesn’t really work in any reliable way. We’re subscribed to updates on all networks, but only remember what happened with the last network that had an update. That means that if, say, the device gains wifi and then loses cellular, we’ll end up thinking there’s no connection, because the cellular connection was the last to update.

In particular I think this means that the code as it currently is will work unreliably even for the motivating use case of #443: if the app-specific wifi network becomes available, but then some other network goes away, we’ll stop thinking there’s a connection at all.

A working version of the feature #443 was meant to implement would probably involve keeping around a data structure with information on all the different networks that are currently available. This probably isn’t super hard, but will require someone to do some work to write it.

If that doesn’t happen, or until that happens, probably the best thing is to revert #443. The library then won’t offer the functionality of giving information about networks other than the default network. But it will again reliably provide what it does offer, which is information about the default network.