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.
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.
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.
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.
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).