Add try/cach to extension bundle

[david-mccullars]

Temporarily hack the built javascript bundle for extensions by adding a try/catch around the entire script. This ensures that any unexpected error that may occur gets output to console log and not swallowed by our web worker.

WHY are these changes introduced?

When developing native UI extensions for POS, it is possible to get into a state where the extension fails to load. The Smart Grid tile just says "Error loading extension," but there is no further information available. Trying to use chrome://inspect shows no console error messages whatsoever, leaving a partner with no good avenue to debug.

WHAT is this pull request doing?

This PR is a possible short-term solution that ensures that the extension bundle that we build is wrapped in a try/catch so that any error is properly caught and output to the console. Long-term, we should consider modifying the web worker which calls importScript to either do a try/catch or ensure that errors are properly reported.

How to test your changes?

One easy way of getting into this state is to create a new POS UI extension and then to make the following change to your src/index.js file:

throw new Error("Simulate a catastrophic error");
render('Retail::SmartGrid::Tile', () => <SmartGridTile />);
render('Retail::SmartGrid::Modal', () => <SmartGridModal />);

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
• Existing analytics will cater for this addition
• PR includes analytics changes to measure impact

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've made sure that any changes to dev or deploy have been reflected in the internal flowchart.

[github-actions]

Thanks for your contribution!

Depending on what you are working on, you may want to request a review from a Shopify team:

• Themes: @shopify/theme-developer-tools
• UI extensions: @shopify/ui-extensions-cli
  • Checkout UI extensions: @shopify/checkout-ui-extensions-api-stewardship
• Hydrogen: @shopify/hydrogen
• Other: @shopify/cli-foundations

[github-actions]

Benchmark report

The following table contains a summary of the startup time for all commands.

Status	Command	Baseline (avg)	Current (avg)	Diff
🟢	app build	946.33 ms	967.67 ms	2.25 %
🟢	app deploy	1179.33 ms	1177 ms	-0.2 %
🟢	app dev	1160 ms	1182 ms	1.9 %
🟢	app env pull	1075.67 ms	1065.67 ms	-0.93 %
🟢	app env show	1047 ms	1079 ms	3.06 %
🟢	app function build	944.33 ms	955 ms	1.13 %
🟢	app function run	940 ms	956.33 ms	1.74 %
🟢	app function schema	1081.67 ms	1090.67 ms	0.83 %
🟢	app function typegen	949.33 ms	956.67 ms	0.77 %
🟢	app generate extension	1137 ms	1143.33 ms	0.56 %
🟢	app generate schema	1087 ms	1113.33 ms	2.42 %
🟢	app info	1049.67 ms	1078 ms	2.7 %
🟢	app scaffold extension	1135 ms	1161 ms	2.29 %
🟢	app update-url	1041.67 ms	1054.67 ms	1.25 %
🟢	theme check	888 ms	924.33 ms	4.09 %
🟢	theme console	990.67 ms	1012.67 ms	2.22 %
🟢	theme delete	1012 ms	1030.67 ms	1.84 %
🟢	theme dev	1025.67 ms	1015 ms	-1.04 %
🟢	theme help-old	893.33 ms	937.33 ms	4.93 %
🟢	theme info	947.33 ms	950 ms	0.28 %
🟢	theme init	920.33 ms	919 ms	-0.14 %
🟢	theme language-server	902.33 ms	898.33 ms	-0.44 %
🟢	theme list	1014.67 ms	1021.67 ms	0.69 %
🟢	theme open	1019.33 ms	1017.67 ms	-0.16 %
🟢	theme package	952.67 ms	986.33 ms	3.53 %
🟢	theme publish	1021.33 ms	1058.33 ms	3.62 %
🟢	theme pull	1041.33 ms	1039 ms	-0.22 %
🟢	theme push	1034.67 ms	1028.67 ms	-0.58 %
🟢	theme serve	1019 ms	1031.67 ms	1.24 %
🟢	theme share	1007.33 ms	1015 ms	0.76 %
🟢	webhook trigger	1030.67 ms	1066.33 ms	3.46 %

[heltisace]

🚀, having these debug logs would be super helpful. I'm definitely down to merge this as a temporary fix.

[heltisace]

@vividviolet can you give us your blessing to ship this as a hotfix to retrieve the error logs? I know you've contributed to CLI a bit in the past and also have very good context on UI Extensions.

Ideally, we would need to modify a sandbox worker but as POS UI Extensions are already in Early Access and we've been getting complains from partners about not being able to see errors, this would at least unblock us from a product point of view.

[vividviolet]

Can you clarify why this issue happens on POS? Should this not be happening for all extensions if it's related to importing an erroneous script? Also, I'm not sure I'm comfortable with adding a try/catch around the partner's code. This would prevent errors from being caught higher up the chain while loading extensions which we might be already doing.

Wouldn't it make more sense for POS or other hosts to do try/catch when loading in the partner's script instead?

[heltisace]

@vividviolet, from what I understand, yes, it should be an issue with other platforms too, not only POS.

Re: adding try/catch logic on POS. The extension loading currently happens in this place. Adding a try/catch there doesn't work because the errors get swallowed somewhere inside the package during the script loading phase. On our side, the extension just doesn't load and we receive an ReadyState.Error. Example.

@david-mccullars might have more context, he spent quite a bit of time investigating this all previously.

[vividviolet]

The proper place would be inside the worker itself before calling importScript. Basically inside the worker.load method.

[david-mccullars]

Wouldn't it make more sense for POS or other hosts to do try/catch when loading in the partner's script instead?

It absolutely would. I spent the better part of two days trying to accomplish this, but I could never get the worker code to build. (I'm not even 100% certain I was in the right place.) This PR wasn't really intended to be a real PR but was put together to help @henrytao-me see the issues I was experiencing when an extension fails to load without communicating anything meaningful to end users. However, partners are running into the same issue, and @heltisace was thinking this might provide some relief until we can figure out the long-term solution. We definitely welcome any thoughts or advice!

[heltisace]

The proper place would be inside the worker itself before calling importScript. Basically inside the worker.load method.

@vividviolet would you be able to help us do that?

[vividviolet]

Yes, I can. I think you are using the same worker script from web correct? @henrytao-me do you remember?

[heltisace]

@vividviolet, I think we are, I looked into this pretty deep at some point too. I think this is the place that needs to be modified.

[heltisace]

Here is a cdn link to the worker we are using: https://cdn.shopify.com/shopifycloud/web/assets/v1/admin-ui-extensions-host/sandbox-worker.worker.js. I got it from the react-native-argo package, ArgoExtension.js file.

[vividviolet]

Yup, that's the same worker used by web. It's strange that we can't catch errors outside of the worker though, I thought this PR to Remote UI was supposed to let us do that: Shopify/remote-dom#173

Have you tried bumping the remote-ui version?

[henrytao-me]

@david-mccullars @heltisace: can you try to update to latest version of remote-ui?

I agree with @vividviolet, the better place for this would be in the worker in Web.

[heltisace]

I'm checking right now. I think both POS and the UI Extensions package are not up to date so I will update both and see what happens.

[heltisace]

After updating the package on the host (POS), the console now throws the errors in the inspect console as expected. We throw an error before the extension loads.

I tried to update the client (UI Extensions) too, but it didn't work. This could have been a local issue though, because I used yalc to link the UI Extensions update to POS and the extension.

Next steps:

• I will create a PR in the POS repo to update the packages.
• We will communicate to the partners that this will be improved in the next version of POS.
• We will look into making it more clear on how to debug UI Extensions so that the partners don't expect the CLI console to present the errors.

Thanks everyone!

cc: @vividviolet @david-mccullars @henrytao-me

[vividviolet]

tried to update the client (UI Extensions) too, but it didn't work.

I don't think you need to update the client libraries because the endpoint set up comes from the host code inside the worker. It should be good enough to just update POS and the pos-next-react-native library.

[heltisace]

That's what we decided to do, yeah.