react-native-netinfo: isInternetReachable returns false even internet is connected

Environment

System:
    OS: macOS 12.2.1
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
    Memory: 30.75 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 18.2.0 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.9.0 - /usr/local/bin/npm
    Watchman: 2022.05.16.00 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 15.4, macOS 12.3, tvOS 15.4, watchOS 8.5
    Android SDK:
      API Levels: 26, 29, 30, 31, 32
      Build Tools: 28.0.3, 29.0.2, 30.0.2, 30.0.3, 31.0.0, 32.0.0, 32.1.0
      System Images: android-26 | Google Play Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom, android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom, android-31 | Google APIs Intel x86 Atom_64, android-31 | Google Play Intel x86 Atom_64
      Android NDK: Not Found
  IDEs:
    Android Studio: 2021.1 AI-211.7628.21.2111.8139111
    Xcode: 13.3/13E113 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.11 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.2 => 17.0.2
    react-native: ^0.66.4 => 0.66.4
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Platforms

Android

Versions

Android:
iOS:
react-native-netinfo: ^8.3.0
react-native: ^0.66.4
react: 17.0.2

Description

Sometimes isInternetReachable returns false even when interent connection is active. Actually, the issue persists when enabling Airplane mode after that isInternetReachable returns false. but if we remove Airplane mode then WIFI connects automatically and is also able to do API requests but isInternetReachable still returning false.

This behavior occurs sometime only. otherwise, it works perfectly.

we use useNetInfo() hooks to identify isInternetReachable status.

import { useNetInfo } from "@react-native-community/netinfo";

const NetworkConnection = () => {
  const netInfo = useNetInfo();
  const isNoConnection =
    (netInfo?.type !== "unknown" &&
      netInfo?.type !== "none" &&
      netInfo?.isInternetReachable === false) ||
    (netInfo?.type !== "unknown" && netInfo?.type === "none");
  return (
    <View style={CommonStyles.flexRoot}>
      {isNoConnection ? (
        <View style={STYLES.noInternetContainer}>
          <FontedText
            text="No internet connection"
            fontSize={widthToDp(14)}
            fontFamily={AppFonts.DMSansRegular}
            color={Colors.darkRed}
          />
        </View>
      ) : null}
    </View>
  );
};

Reproducible Demo

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 18
Comments: 21 (6 by maintainers)

Most upvoted comments

PLEASE DO NOT POST METOO COMMENTS. They are spam and I will lock the issue if they continue.

mikehardy on Sep 17, 2022

Let’s check the issues: https://github.com/react-native-netinfo/react-native-netinfo/issues?q=is%3Aissue+is%3Aopen+isInternetReachable

Wow! 28 of them open. I guess we should sort by “most commented”, maybe (just maybe…) people have dug in to this

https://github.com/react-native-netinfo/react-native-netinfo/issues?q=is%3Aissue+is%3Aopen+isInternetReachable+sort%3Acomments-desc

Here’s the top one

https://github.com/react-native-netinfo/react-native-netinfo/issues/400

Perhaps that one has bearing and this is just duplicate?

Either way: any + all reasonable PRs will be merged. Comments are…interesting but you must admit at the end of the day they do not fix the bug. You can be the hero we all need: determine the root cause, develop a fix, post a PR. I will merge it. It will release. The internet will rejoice.

This is not a use case of mine though and I’m the only maintainer left in this repo so I want to be crystal clear on expectations: I am not spending a single second fixing this bug. Someone needs to post a PR. Not saying that to be mean or anything but unclear expectations are bad so this one is clear now, yes? Post a PR if this is important to you.

mikehardy on Sep 19, 2022

Those comments are spam to some, me included.

https://hackernoon.com/i-thought-i-understood-open-source-i-was-wrong-cf54999c097b

mikehardy on Aug 24, 2022

Facing the same issue

JensenBlake on Aug 24, 2022

me too

phucph1998 on Aug 11, 2022

Fantastic news @veeramani-arthanari ! If that’s the case and there are more success reports you all @Sachin926 a virtual beer or 🏆 because he stepped in on the issue and within a couple hours of apparently deciding “Hey, maybe I can fix this”, they fixed it with PR #624 - that’s what it takes - don’t post metoo comments forever, just open the code do some diagnostics and post a fix, and we’ll all keep open-source-ing along 😉

mikehardy on Sep 26, 2022

@luckydunia054 (and anyone else that does not read the thread), this is my definitive statement on the matter.

Either way: any + all reasonable PRs will be merged. Comments are…interesting but you must admit at the end of the day they do not fix the bug. You can be the hero we all need: determine the root cause, develop a fix, post a PR. I will merge it. It will release. The internet will rejoice.

This is not a use case of mine though and I’m the only maintainer left in this repo so I want to be crystal clear on expectations: I am not spending a single second fixing this bug. Someone needs to post a PR. Not saying that to be mean or anything but unclear expectations are bad so this one is clear now, yes? Post a PR if this is important to you.

mikehardy on Oct 27, 2022

Great experiment results - thank you - only commenting to add that from my understanding of iOS app lifecycle, iOS kills (they say “suspends”) apps aggressively in background, so after a few seconds (about 5) the app will transition from background to suspended, and it is likely it will be purged from memory (“killed” in a way, but not “force killed”, that’s different in iOS terms - that’s where the user killed it and the system now won’t run background code even periodically).

https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle?language=objc

perhaps the lifecycle hook for entering foreground needs to be used for iOS in this module to force refresh state, based on the assumption that while in background state was perhaps changing without the app being aware, so state-from-background-time may not be trusted 🤔

mikehardy on Oct 31, 2022

Haven’t determined the root cause yet, but here are steps I’ve found to repro it 100%:

Run the example app in release mode on iOS device (worked fine in the simulator).
Put the app into background by switching to another app.
Wait 60 seconds (OS on iOS does something with the app to break the lib logic?).
Switch back to the example app and see observe Info History in the example app showing an entry { isConnected: true, isInternetReachable: false, ... } I expect isInternetReachable to stay true

I’ll make a PR once there’s an understanding what goes wrong exactly, but ideas on where to look are welcome 🤞

Edit: A few more details. Realised that the magical 60 seconds is just the default value of reachabilityLongTimeout, which triggers a new reachability check.

As soon as the app goes back to “active” state and has a chance to run the fetch, a cryptic TypeError: Network request failed 🤔 (perhaps related to the suspended state?) is thrown with solid network. It causes an update to the internal state of false (relevant part here https://github.com/react-native-netinfo/react-native-netinfo/blob/v9.3.5/src/internal/internetReachability.ts#L119).

A temp solution is to ignore such internal updates while app state is not ‘active’.

rrebase on Nov 1, 2022

facing the same issue on the android and ios both devices. isConnected and isInternetReachable Returning false even when there is internet connected

prashantkamboj on Sep 16, 2022