Issue-1473: App Crash with Invalid scriptURL #1476

morganick · 2024-05-02T15:01:09Z

Please verify the following:

yarn build-and-test:local passes
I have added tests for any new features, if relevant
README.md (or relevant documentation) has been updated with your changes

Describe your PR

Fixes #1473 where calling split on an invalid string throws a TypeError.

In the event that the following line does not provide us with a valid URL:
https://github.com/facebook/react-native/blob/b38f80aeb6ad986c64fd03f53b2e01a7990e1533/packages/react-native/React/CoreModules/RCTSourceCode.mm#L38

We should catch this and warn the user that we are falling back to the default host:

WARN  getHost: "Invalid URL: null" for scriptURL - Falling back to localhost

How to Reproduce

I was unable to reproduce this issue locally with my devices as it would not crash the application, but just throw the error. Due to the circumstances of the original issue and that applications configuration, this should allow that application to continue to boot.

Additional Notes

It is still possible to configure Reactotron with an invalid host. This will equally throw an error of invalid url. I'd like to create a new PR that allows the application to continue to function, keeps Reactotron is a disconnected state, and notifies the user.

morganick · 2024-05-02T15:03:50Z

lib/reactotron-react-native/src/reactotron-react-native.ts

+const getHost = (defaultHost = "localhost") => {
+  try {
+    // RN Reference: https://github.com/facebook/react-native/blob/main/packages/react-native/src/private/specs/modules/NativeSourceCode.js
+    return new URL(NativeModules?.SourceCode?.getConstants().scriptURL).hostname


Didn't see any reason not to use URL class here for this purpose:
https://github.com/facebook/react-native/blob/b38f80aeb6ad986c64fd03f53b2e01a7990e1533/packages/react-native/types/modules/globals.d.ts#L396

IIRC Hermes URL implementation has some problems. Josh has commented on this: facebook/hermes#1072 (comment). I'm not sure of the current state, but looking...

From https://www.npmjs.com/package/react-native-url-polyfill, they claim it doesn't work with 'localhost' properly (facebook/react-native#26019), and creating new URLs can throw exceptions (facebook/react-native#16434).

I think if we take this route we need to be sure to test it with a non-Expo app, since as that discussion mentions they added their own polyfill. Maybe test the oldest supported RN version too in case changes have been made that I haven't seen.

Looks like the Expo polyfill was doing its job. The above screenshot is from a fresh react native cli app. I'll switch it out with something that handles just this case.

I was unable to use the same package that Expo is using for their URL Here's the scoop:

We use rollup for building the core dependencies into the packages like reactotron-react-native. I was trying to use a package that uses commonjs exports inside of the library. Evidently, Rollup has deprecated the way that is handled and moved it into another package: https://rollupjs.org/troubleshooting/#error-name-is-not-exported-by-module ( I was specifically running into this issue)

I could install that package in any other application, but not for use in our monorepo because of rollup... but I didn't figure that out until this morning because after I removed it... reactotron-react-native would no longer build. Even after reverting all of the changes calling yarn clean and yarn reset. It wasn't until I switched branches back to master... where it started to build again. Then I switched back to my branch without the new package and it continued the build 😱

So I was then trying to figure out what cache is not being cleared. (I didn't realize rollup was involved.) Come to find out that I believe the nx cache is cleared when you switch branches and code changes in that dep. So in order for me to reliably add that package and not foobar the build I would have to run yarn nx reset && yarn reset.

I have updated our yarn reset script for this reason to include a call to yarn nx reset.

I moved this to being a regex for now until we can do the prerequisite Rollup upgrades.

morganick · 2024-05-02T15:04:20Z

lib/reactotron-react-native/src/reactotron-react-native.ts

-    : defaultHost
+const getHost = (defaultHost = "localhost") => {
+  try {
+    // RN Reference: https://github.com/facebook/react-native/blob/main/packages/react-native/src/private/specs/modules/NativeSourceCode.js


This URL gives you more context as to what's available with this native module. I can change it back to the old link if that's more clear.

morganick · 2024-05-03T19:02:16Z

lib/reactotron-react-native/src/reactotron-react-native.ts

+    if (typeof scriptURL !== "string") throw new Error("Invalid non-string URL")
+
+    // Using a capture group to extract the hostname from a URL
+    const host = scriptURL.match(/^(?:https?:\/\/)?([^/:\s]+)(?::\d+)?(?:[/?#]|$)/)?.[1]


Test cases: https://regex101.com/r/WIHVuQ/2

Future 🤔 ...

We could try to use the built in URL class if it has the host or hostname implemented. This would work in current Expo applications. We could then fall back to the regex if that's not available.

Reasons:

Using what's there so it stays in line with what the application is already using

More robust support for URLs - The regex above does not support IPv6.

Hope that URL parsing gets fully implemented so that it's available across the board without polyfill or external packages and then we can remove the regex.

For now, we'll utilize the regex until we can either import the standardized URL parser or it becomes a first class citizen of the platform. To @lindboe point, having one solution means the potential bug reports will be simpler to triage.

Could we put these regex in the codebase as unit tests? That way we can add more tests if we have more URL issues in the future.

One thing I like to do with regexes is comments that explain their matching section-by-section (here it seems feasible to do per-capture group) just to make sure everybody's on the same page about what's intended

Unit tests aren't a bad idea either 😄

morganick · 2024-05-03T19:02:54Z

scripts/reset.sh

@@ -1,5 +1,8 @@
 #!/bin/bash

+echo "Nx Reset - Clears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon."
+yarn nx reset
+


@joshuayoes https://nx.dev/nx-api/nx/documents/reset

morganick · 2024-05-03T19:23:54Z

@lindboe I have validated this with Expo apps on my devices, simulator, and emulator for both iOS and Android. I also validated this on device Android and iOS simulator with RN 0.74 app using RN cli.

Could you take this for a spin inside your application on your devices to make sure we've covered the cases we need to.

joshuayoes

This looks like a good solution! I left one comment about adding unit tests I'd like to see but this PR could be merged in as is

lindboe

Tested it out, looks like it works as intended.

migueldaipre · 2024-05-08T14:16:44Z

Hey guys, any news on when this will be released?

lindboe · 2024-05-09T21:23:09Z

lib/reactotron-react-native/src/helpers/parseURL.test.ts

+  it("should get host from URL without scheme", () => {
+    Object.entries({
+      localhost: "localhost",
+      "127.0.0.1": "127.0.0.1",


do we need to match on ipv6?

Lol, this was the 🐰 🕳️ I was trying to avoid 😜 I have an idea for tomorrow.

Hey, fair enough, you can tell me you don't think we need it! I have no idea whether we do or not.

I've added IPv6 and exp:// schema for Expo Go.

exp:// may not be needed, but I included it as when you run expo start it says that metro is waiting on exp://192.168.1.x:8081 so if that comes through on the scriptURL we'll handle it.

I added specs for both IPv6 and exp schema.

lindboe · 2024-05-09T21:29:05Z

lib/reactotron-react-native/src/helpers/parseURL.test.ts

+    })
+  })
+
+  it("should get the host from URL and ignore path, port, and query params", () => {


Should we also test with Expo tunnel-style URLs? https://docs.expo.dev/more/expo-cli/#tunneling.

I'm not quite sure how to support tunneling honestly. I think you'd have to create a tunnel for each port that you wanted to connect to. This is something I'd probably reach for Tailscale for... which reminds me I should create a blog post for that. Either way, I think we'd still get the host right for it. Just would have to make sure we forwarded the right ports to Reactotron, yes?

With this comment I only meant we should check we don't break anything that wasn't broken for Expo's tunneling support. I'm not sure if exp:// is used there for hosting the JS bundle, I thought maybe it was just used for deep links now? Not sure.

It appears to work with Expo Go without it. Removed.

@lindboe In order to support tunneling, I believe we'd have to have some way to know to include the port. This PR only replaces the old method of finding the host with safeguards around not crashing the application if the URL is not valid. Maybe we tackle that in another PR?

Yeah that makes sense 👍

morganick · 2024-05-13T20:10:44Z

@joshuayoes I went full regex based on our conversation on Friday.

lindboe

Looks good!

morganick added 2 commits May 2, 2024 10:48

Use URL to parse URLs

4beeb2d

Adding NativeModule ref link

a4619bd

morganick commented May 2, 2024

View reviewed changes

morganick self-assigned this May 2, 2024

morganick requested review from frankcalise and lindboe May 2, 2024 15:33

morganick added the bug 🪲 Nope, this is wrong. label May 2, 2024

morganick marked this pull request as ready for review May 2, 2024 15:33

morganick added 2 commits May 3, 2024 14:21

Make sure we also reset Nx cache

ff96fe2

Using regex for host and falling back to defaultHost

b63fe4f

morganick commented May 3, 2024

View reviewed changes

joshuayoes approved these changes May 6, 2024

View reviewed changes

lindboe approved these changes May 7, 2024

View reviewed changes

Adding tests for getHostFromUrl functionality

00571e1

morganick requested review from joshuayoes and lindboe May 9, 2024 21:14

lindboe reviewed May 9, 2024

View reviewed changes

morganick added 2 commits May 13, 2024 15:20

Add expo go URL scheme

1fa045e

Adding support for IPv6

e74153f

morganick requested a review from lindboe May 13, 2024 20:10

Removing exp scheme support - not needed

c3940d4

lindboe approved these changes May 14, 2024

View reviewed changes

morganick merged commit d45ee2a into master May 15, 2024
2 checks passed

morganick deleted the morganick/issue-1473-ios-app-crash-on-device branch May 15, 2024 13:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue-1473: App Crash with Invalid scriptURL #1476

Issue-1473: App Crash with Invalid scriptURL #1476

morganick commented May 2, 2024 •

edited

Loading

morganick May 2, 2024

lindboe May 2, 2024

morganick May 2, 2024

morganick May 3, 2024

morganick May 2, 2024

morganick May 3, 2024

morganick May 3, 2024

joshuayoes May 6, 2024

lindboe May 7, 2024

morganick May 3, 2024

morganick commented May 3, 2024

joshuayoes left a comment

lindboe left a comment

migueldaipre commented May 8, 2024

lindboe May 9, 2024

morganick May 9, 2024

lindboe May 10, 2024

morganick May 13, 2024

morganick May 13, 2024

lindboe May 9, 2024

morganick May 13, 2024

lindboe May 13, 2024

morganick May 13, 2024

morganick May 13, 2024

lindboe May 13, 2024

morganick commented May 13, 2024

lindboe left a comment

Issue-1473: App Crash with Invalid scriptURL #1476

Issue-1473: App Crash with Invalid scriptURL #1476

Conversation

morganick commented May 2, 2024 • edited Loading

Please verify the following:

Describe your PR

How to Reproduce

Additional Notes

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

morganick commented May 3, 2024

joshuayoes left a comment

Choose a reason for hiding this comment

lindboe left a comment

Choose a reason for hiding this comment

migueldaipre commented May 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

morganick commented May 13, 2024

lindboe left a comment

Choose a reason for hiding this comment

morganick commented May 2, 2024 •

edited

Loading