@ffMathy Experiencing the same problem. Did you find a solution?

Copying over @edi's report from #17917, which is more complete

Summary

So, on Android, for some reason the path of the AppBundle file that it is trying to fetch, is relative, instead of absolute.

Basically, it tries fetching /Users/edi/Desktop/Swup/http:/192.168.3.12:8081/node_modules/expo/AppEntry.bundle [etc]

When in fact, the file is actually available, but http:/192.168.3.12:8081/node_modules/expo/AppEntry.bundle [etc] is available with the proper info.

So for some reason, it tries parsing the file with current working dirrectory in front /Users/edi/Desktop/Swup/
I've tried reinstalling everything, but the same happens .. any clue what could cause this? iOS works fine.

Managed or bare workflow? If you have made manual changes inside of the ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

Android

Package versions

expo-dev-client@~1.0.0
firebase@9.6.0 (tried with most v9.x.x versions, same issue)

Environment

expo-env-info 1.0.3 environment info:
System:
  OS: macOS 12.4
  Shell: 5.8.1 - /bin/zsh
Binaries:
  Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node
  npm: 8.12.1 - ~/.nvm/versions/node/v16.15.1/bin/npm
SDKs:
  iOS SDK:
    Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
IDEs:
  Android Studio: 2021.2 AI-212.5712.43.2112.8609683
  Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
npmPackages:
  expo: ~45.0.0 => 45.0.5 
  react: 17.0.2 => 17.0.2 
  react-dom: 17.0.2 => 17.0.2 
  react-native: 0.68.2 => 0.68.2 
  react-native-web: 0.17.7 => 0.17.7 
npmGlobalPackages:
  eas-cli: 0.54.1
  expo-cli: 5.4.11
Expo Workflow: managed

Reproducible demo

Make sure to install firebase v9+ in the project, that's it.

import {getFirestore} from 'firebase/firestore'
import {initializeApp} from 'firebase/app'
import {useState, useEffect} from 'react'

import {
  View,
  Text,
  StyleSheet
} from 'react-native'

import {
  query,
  limit,
  orderBy,
  getDocs,
  collection
} from 'firebase/firestore'

initializeApp({projectId: 'oneplayjs', apiKey: 'AIzaSyB54sfNu6X4ka-H2Vz5il-_nSNrLbJL2Gk'})
const db = getFirestore()

const fetchStations = async callback => {

  let q = query(
    collection(db, 'stations'),
    orderBy('priority'),
    limit(100)
  )

  return getDocs(q)
    .then(snapshot => {
      let items = snapshot.docs.map(item => item.data())
      callback(items)
    })
    .catch(err => console.log(err.message))

}

export default function App() {

  const [stations, setStations] = useState([])

  useEffect(() => {
    fetchStations(list => setStations(list))
  }, [])

  return (
    <View style={styles.container}>
      {stations.map(item =>
        <View key={item.objectId} style={{marginBottom: 10}}>
          <Text>{item.title}</Text>
        </View>
      )}
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  }
});

As you can see, It doesn't have any custom config, no plugins, nothing aside firebase.

• web, works fine (expo go and dev client).
• iOS, works fine (expo go and dev client).
• android works fine in Expo go, but dies when using the dev client, with the above error.

I doubt it's an issue with Firebase since it works just fine in a production build, on all platforms, as well as within expo go directly, just fails for some unknown reason on Android's dev client, which makes development impossible.

What I've tried so far:

1. Tried with most Firebase v9 versions, starting with 9.0.0, all the way to 9.8.3 which requires that metro.config.js file to support .cjs extensions, issue is the same.

2. Tried modifying readFileSync directly in node's FS source code (node_modules), just to make sure it's not that AppEntry.bundle file that cannot be loaded and causes it, still, even when loaded, issue is the smae.

3. Tried on a different laptop (macOS) as well as a different PC (Windows), result is the same.

4. Tried on a different phone (even though it should have nothing to do with it) as well as on different development builds, all cleaned up, same story.

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

I'm getting the same issue with iOS on our custom dev client. Is there a known workaround?

@jedahan I noticed the exact same issue on iOS just yesterday, but it seems to happen only when there's an uncaught error happening in Firebase ... which is so weird, as it does not happen in production, but seems to happen in the dev-client.

If I catch the error, nothing happens on iOS, whereas, it happens all the time on Android, if I initiate Firebase.

I am not using firebase, but maybe it also is a problem with sentry-expo.

Quick recap:

If you simply initiate firebase in any development client on Android and call any method, you'll see the error. This also causes firebase to not connect to Google's backend at all ... so it's impossible to use the Android dev-client with firebase currently. Whereas on the iOS dev client, firebase works just fine, but the above error happens only when code crashes via an uncaught error. Doing a try/catch on the crashing bit of code, makes the code run just fine on iOS.

Everything seems to work just fine in the standalone builds though, so .. not sure what's wrong with the dev-client.

@jedahan Ah, okay then, so now we have two things that trigger the same error. Maybe related to some sort of socket connection since both sentry and firebase use sockets to connect to their backend?

I happen to have some sort of the same issue, but with a different file being opend, which doesn't seems to belong to my computer/user (hardcoded strings i'm looking at you) =>

• Expo 45
• RN 0.68.2
• Using Firebase (RN-Firebase)
• Using Dev client
• Using hermes
• Not using new arch' or Fabric (yet)

Basically the app runs fine, but it throws this in the console for whatever reason multiple times, cannot seem to find a "pattern" of when this happens tho.

Error: ENOENT: no such file or directory, open '/Users/distiller/hermes/build_iphonesimulator/lib/InternalBytecode/InternalBytecode.js'
    at Object.openSync (node:fs:585:3)
    at Object.readFileSync (node:fs:453:35)
    at getCodeFrame (/Users/admin/Dev/MyApp/node_modules/metro/src/Server.js:949:18)
    at Server._symbolicate (/Users/admin/Dev/MyApp/node_modules/metro/src/Server.js:1022:22)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at Server._processRequest (/Users/admin/Dev/MyApp/node_modules/metro/src/Server.js:429:7) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/Users/distiller/hermes/build_iphonesimulator/lib/InternalBytecode/InternalBytecode.js'
}

PS: Just to clarify, my home directory is /Users/admin, not /Users/distiller and I cannot find where this comes from, but it seems to be the same error stack trace as in original post

Alright, more insight from my part.

On the android dev-client, the reason libraries like sentry-expo or firebase don't work is because it does not seem to have proper support for websockets or something, because, if you set experimentalForceLongPolling: true when initializing the Firebase app, everything works fine. Since Sentry also uses sockets to pass data around, I assume the issue is exactly the same.

However, the ENOENT issue above seems to be somehow caused at the same time when the above issue fails, no clue what's triggering it ...

But if there's no uncaught errors in the app, there's no ENOENT error either .. so I'm sure something's related.

I don't have sentry-expo or firebase in my project, yet I get the same error:

Error: ENOENT: no such file or directory, open '/home/kleinhenz/Source/titan-mobile/http:/192.168.178.131:19000/node_modules/expo/AppEntry.bundle?platform=android&dev=true&hot=false&strict=false&minify=false'
    at Object.openSync (node:fs:506:3)
    at Object.readFileSync (node:fs:402:35)
    at getCodeFrame (/home/kleinhenz/Source/titan-mobile/node_modules/metro/src/Server.js:949:18)
    at Server._symbolicate (/home/kleinhenz/Source/titan-mobile/node_modules/metro/src/Server.js:1022:22)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at Server._processRequest (/home/kleinhenz/Source/titan-mobile/node_modules/metro/src/Server.js:429:7) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/home/kleinhenz/Source/titan-mobile/http:/192.168.178.131:19000/node_modules/expo/AppEntry.bundle?platform=android&dev=true&hot=false&strict=false&minify=false'

I am blocked :-/

Any other packages that might be using sockets to connect to backend?

Either way, don't worry about it not working in production, you can try a testflight build to double check, but it only seems to affect the development client, whatever the issue is with it.

Yes, the app itself uses websockets to connect to it's backend, so ws all over the place. And it's in development and not yet in production, so I am blocked :-/

For everyone blocked: manually adding the change from https://github.com/facebook/metro/pull/841/files into your node_modules makes it tick again. Not a long-term solution though, obviously.

(Metro maintainer here).. I haven't looked into this beyond reading this issue and Metro PR yet, but I'm keen to understand what's going on.

@gavin1995's PR is a welcome clue but it suppresses the error by skipping over the "invalid" lines of stack traces being sent to Metro. To get to the root cause (and have complete stack traces) we need to know where those invalid lines (URLs, whereas Metro only handles file paths) are coming from.

Those requests to Metro are symbolication requests - probably triggered by an attempt to log an arbitrary (unrelated) stack trace. I think that explains why people are seeing this issue for seemingly unrelated root causes and sometimes only in development - effectively it's an error-reporting error.

I'd be happy to investigate this but a minimal (or really any open source) repro would be hugely helpful.

@robhogan hey, you can check my issue for a reproducible demo using firebase, here: #17917

In order to trigger the error every time, please connect to a firebase device.

Hey! Was this fixed on SDK 46?

Hey! Was this fixed on SDK 46?

I am still getting this on 46, so I don't think so

Works for me now with 46. Not sure what is different. Comms are really bad here. There was something done, but no one tells if this is actually fixed. I'd consider this a major issue.

We face the same issue here, but it only happened for Android. This message is not helpful and unrelated to the issue we were having. I believe that this was the reason this error was omitted from version 46 (not sure, though).

If you are still facing this issue with ENOENT with this weird index.bundle path/url, I would suggest debugging deeper and trying to find the real root cause of the issue.

We face the same issue here, but it only happened for Android. This message is not helpful and unrelated to the issue we were having. I believe that this was the reason this error was omitted from version 46 (not sure, though).

If you are still facing this issue with ENOENT with this weird index.bundle path/url, I would suggest debugging deeper and trying to find the real root cause of the issue.

As mentioned above the error comes from a failure in the logging of another error, if my understanding is correct what happens it:

1. Something goes wrong in your app and it throws an error
2. That error is not caught
3. The raw error is sent back to metro for symbolicating before being logged/alerted
4. For some reason the error gets incorrect data in it
5. Metro tries to read that file to figure out more info about the error but it doesn't exist
6. Metro throws a fit and logs an error about not finding the file from step 5, and (usually) failing to log any information about the error in step 2

That incorrect data (the file it fails to open) has been reported to be one of the following:
/Users/distiller/hermes/build_iphonesimulator/lib/InternalBytecode/InternalBytecode.js
C:\Users\distiller\react-native\sdks\hermes\build_iphoneos\lib\InternalBytecode\InternalBytecode.js
*always distller, regardless of your actual username`

-or-

/home/{ACTUAL_USERNAME}/{PATH_TO_APP_DIR}/http:/{IP_ADDRESS}:19000/node_modules/expo/AppEntry.bundle?platform=android&dev=true&hot=false&strict=false&minify=false
C:\Users\{ACTUAL_USERNAME}\{PATH_TO_APP_DIR}\http:\/{IP_ADDRESS}:8081\index.bundle?platform=android&dev=true&hot=false

There seem to be two manifestations of the same bug, one due to a hardcoded path looking for hermes bytecode, and the other looking for the app bundle file.
It seems possible that the hermes error shows up for iOS and the bundle error for android, but that's just a guess based on the limited samples shown here

Work for me to delete the repo and re-clone

@Jessen94 what repo did you delete?

@EvanBacon fixed custom symbolication to work around this in #18255 (@expo/metro-config@0.3.22). It looks like you should get this fix by refreshing your node_modules with any version of SDK 46, but it's not backported to SDK 45.

To confirm, this is a bug with printing (symbolicating) an error or warning. The underlying error/warning could have almost any root cause.

That said, I'd like to get to the bottom of where these URL file paths are actually coming from before we bring in a fix on the Metro side - I've tried this with --template=blank@45 - but haven't been able to reproduce the issue myself. URLs aren't invalid per-se but these ones obviously relate to local bundles, and we ought to be able to provide proper code frames for them rather than dropping them.

Edit: URLs here are sometimes expected but Metro was failing to skip over them when building a code frame. Opened facebook/metro#910 to fix.

@EvanBacon fixed custom symbolication to work around this in #18255 (@expo/metro-config@0.3.22). It looks like you should get this fix by refreshing your node_modules with any version of SDK 46, but it's not backported to SDK 45.

To confirm, this is a bug with printing (symbolicating) an error or warning. The underlying error/warning could have almost any root cause.

That said, I'd like to get to the bottom of where these URL file paths are actually coming from before we bring in a fix on the Metro side - I've tried this with --template=blank@45 - but haven't been able to reproduce the issue myself. URLs aren't invalid per-se but these ones obviously relate to local bundles, and we ought to be able to provide proper code frames for them rather than dropping them.

Well the bundle ones might not be invalid but I don't think anyone knows (or at least has said here) who distiller is or why their name is in our error logs.

Well the bundle ones might not be invalid but I don't think anyone knows (or at least has said here) who distiller is or why their name is in our error logs.

True, those ones are legitimately invalid baked-in paths and won't be fixed by @EvanBacon's patch. The error from Metro in that case is right (if a bit noisy) - distiller looks like a legacy of a CircleCI acquisition so it's probably the build location in OSS CI.

Edit Yes, these are baked in during the Hermes builds as part of the React Native CI. The source (eg InternalBytecode.js) is generated and not distributed so there's no right place to read it from, but I guess we could build in a special prefix instead like Node's node:internal so Metro could know to skip these files.