Fetch catch error returns an Expo line error on live app

On my standalone production iOS app, started happening yesterday where my fetch calls 2-3 times returned an Expo error message (as if I was on DEV). For example my fetch to my server returned: {"line": 913, "column": 4879, "sourceURL": "https://d1wp6m56sq74a.cloudfront.net/${myexponame}${myapp}${myversion}${hash?}-31.0.0-ios.js}

The message originates from my airbrake reporting of any erroneous returns. As far as I can tell this came from a 200, so that is very odd. If so, it sounds like Expo has to proxy my fetch call and therefore could be a point of failure. But if so, it should return 500 right?

I’m going to tweak the reporting script to better capture stuff like this to verify where and how it came through.

Here are some more:




Update: Looks like it’s only coming from my Android app. And as I see from the other poster, sounds like some Cloudflare problem serving to Android. Sounds like Expo is failing somewhere in the bundle.

Update: Nope it’s both apps.

1 Like

Hey @ericjames,

Thanks for posting this, I’m looking into it now. Looks like you’re using SDK 31, correct?

Yes correct. SDK 31.

I also suspect it may be originating from a try catch that also reports GA exceptions for us and is a result of parsing Branch.io params being screwy. However that Component is only reached for new users, and the error would not be sent in multiple bursts, and appeared only recently after code changes to methods around our fetch caller.

Thank you!

Expo CLI 2.10.1 environment info:
OS: macOS 10.14.3
Shell: 3.2.57 - /bin/bash
Node: 11.3.0 - /usr/local/bin/node
npm: 6.5.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Android Studio: 3.3 AI-182.5107.16.33.5264788
Xcode: 10.1/10B61 - /usr/bin/xcodebuild
expo: ^31.0.4 => 31.0.6
react: 16.5.0 => 16.5.0
react-native: https://github.com/expo/react-native/archive/sdk-31.0.1.tar.gz => 0.57.1
expo-cli: 2.10.1

Thanks for all the info!

Could you provide a way for us to re-create the error or see the code that’s throwing those JS error objects? That way we can get a better understanding of the root cause. Since it appeared after code changes made around the fetch caller, I would assume that the issue lies somewhere there.

@charliecruzan Here is a Snak where the possible problematic code is in Updater.js. https://snack.expo.io/@ericjames/updater-framework

I am seeing the error continue to be reported this week always {“line”:913,“column”:5202,"

Also to note, the error may be related to when fetch fails with TypeError: Network request failed when the network goes out, maybe there is something Expo isn’t handling well.

The good thing is it’s being recorded as a regular exception, not an app crash.

I just caught the line error throwing just after a Network request failure. I think it has to do with the timeout hack I’m using, it might not be cancelling and triggering its reject and though it should pass back a new Error message, it seems Expo doesn’t like it or something. Probably the clearTimeout which is clearing a timeout it itself is nested inside.

I’ll eventually refactor this to an abort() so we don’t need this wrapping timeout.

@charliecruzan Analytics caught it happening again on our recent app update running Expo 32

In this case I’ve verified it is the error message piped through a fetch().catch(e) statement because the Expo line error came embedded in our reporting string. This occurred in a different fetch function in our app that hasn’t changed in the last few months (it’s a plain fetch call, no options provided).

Manual entry: Validation fetch error: {"line":133,"column":2655,"sourceURL":"https://d1wp6m56sqw74a.cloudfront.net/%40${user}%2F${app}%2F1.0.2%2F7a369a648d49f3221af7cea343a5b4f2-32.0.0-ios.js"}

So it sounds like it’s encountering an issue in the Expo bridge code probably when you receive an iOS datatask error.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.