ChunkLoadError and o.isProxied error

We use Sentry for error logging with our Ionic 5 (Angular with Capacitor) App which is deployed to three platforms (iOS, Android and Web).

In the Sentry we get a lot of these errors coming from the web platform:

ChunkLoadError: Loading chunk XX failed.

We never see these internally, only in production. I think this is something to do with Lazy Loading but I’m not really sure what our approach should be to handle these errors? Does anyone else get them and if so how have you handled them?

We also get a lot of these errors:

undefined is not an object (evaluating 'o.isProxied')

but in the logs these are always proceeded by a Loading chunk XX failed error so I am guessing they are related? Anyone else get these?

We have been getting a lot of the ChunkLoadErrors lately as well. I’d have to go back and look but I think it started after the movement to Ionic 5. I don’t remember them in Ionic v4.

We, too, are using preloadingStrategy: NoPreloading,.

I guess turning that off may be the next thing to try?

We have ours set to:

preloadingStrategy: PreloadAllModules

Let me know if you get anywhere with this!

getting same error, any update or solution ?
Thank you.

I’ve been troubleshooting this same issue… it seems the isProxied error is thrown by Ionic’s stencil component initialization code (stencil/initialize-component.ts at 63dbb47a14cc840c8d37f1bf7ce315d306194788 · ionic-team/stencil · GitHub).

We’ve had some issues with lazy loading modules, where after publishing a new build, anyone with a cached version of the app can encounter ChunkLoadErrors. This article had some good ideas (Angular Lazy Routes & loading chunk failed | by Kamran Khatti | Medium), however I had trouble getting the error handler to fire correctly with Sentry and Ionic.

It seems like the stencil isProxied error is happening because it’s trying to instantiate a component that didn’t get loaded because of a missing .js file / ChunkLoadErrors. The hashes in Angular’s build output are based on the content of the source, not timestamps, so doing a new build may result in the exact same hashes, except for source files that were actually changed on that build.

The challenging part is hearing from customers where our Ionic web client just stops working and requires a refresh whenever we deploy a new build with some significant changes. After some troubleshooting, instead of adding an error handler to the Angular app, I found it easier to implement a server side solution as follows:

  • If someone requests a non-existent .js file from our node server, then we respond with a simple reload.js script that calls window.location.reload() to refresh the user’s browser.
  • To avoid constant redirect loops, I added an expiring cookie to only serve the reload script once per minute.
  • The server is also configured with Cache-Control: public, max-age=0 to discourage caching.

This could probably be optimized further with smarter caching, so long as index.html doesn’t get cached. At some point for this project we’ll be moving to Amazon Cloudfront instead of serving assets off of our Node server. If anyone has figured out how to do client-side error handling on ChunkReloadErrors with Sentry/Ionic 5, that might be more elegant. Anyway, hope this helps someone facing similar issues.