error loading dynamically imported module

[hahn-kev]

Seeing this error in staging. The trace doesn't have any spans in honeycomb so there's nothing else

In the console there was this error: Loading module from “https://staging.languagedepot.org/” was blocked because of a disallowed MIME type (“text/html”).

[rmunn]

I believe https://stackoverflow.com/a/74057337 may explain the cause of this issue. Summary: when Vite compiles bundles, it includes a hash in the filename. When you deploy a new version of the bundle, the hash is different, which forces browser caches to reload it. But what can happen is the following sequence:

• User loads a page where /project/sena-3 points to projectPage.123abc.js
• Deployment runs, uploading a new projectPage.456def.js file and deleting projectPage.123abc.js
• User does not reload the browser page, then clicks the /project/sena-3 link.
• Router tries to load the non-existent 123abc.js page, gets 404 (which might be rendered in text/html), produces this error

https://stackoverflow.com/a/74861436 (another answer on the same SO question) has a suggested answer that works with the Vue router. Don't know yet if a similar approach could be taken in Svelte-Kit.

[myieye]

Yeah, I also think this it's the problem @rmunn suggests. Meaning it's a pretty normal problem. Somehow you have to get an outdated version of a loaded page up to date.

The docs suggest that SK tries to detect and fix this automatically automatically when a relevant error occurs:

If SvelteKit encounters an error while loading the page and detects that a new version has been deployed (using the name specified here, which defaults to a timestamp of the build) it will fall back to traditional full-page navigation.

I think that's what I've generally observed: that this error message sort of just flashes and the page is automatically reloaded, but that might have to do with dev and hmr. The screenshot from the OP suggests the browser stayed on the error page.

I see 2 sort of dumb, but potentially worth trying option (maybe in combination):

• We detect these errors too and reload the page (it's hard to know what that will actually do to users. Did they just click a submit button? Where should we send them? etc.)
• We use import { updated } from '$app/stores' in combination with the version poll config and show an appropriate message and refresh button

[myieye]

The hope is that we can reproduce this locally to same extent by doing something like:

• turn off HMR in Vite
• turn off optimistic loading on hover (just so there's less magic and confusion)
• Load a page
• Rebuild the app
• Try to click a link

It sounds like we

• sometimes catch this error: then we could use the updated store to see if it's due to an update and at the very least make that visible to the user so they know that we know what happened.
• and sometime don't 🤷 catch the error: it which case we might always want to listen to updated and show a toast when it emits

[myieye]

Here's the single recorded occurence in staging. (this link isn't quite as good, but might be more reliable 🤔)

It doesn't actually appear to have anything to do with an app update/deployment. The error was triggered at 8:52 (my time) with a version from 3 days prior and the app was only updated at 9:07. Here's an overview of the requests by version.

It's surrounded by "Function called outside component initialization" errors, which are thrown (for example) when onMount or getContext is called too late. As @hahn-kev noticed, I introduced a bug that caused this patch of errors in both staging (just for a few days - never before or ever again) and dev. Dev, however, has also sporadic occurences before and after the "patch".

So, my working theory is that...I don't know 😉...or the server just failed to serve the module, because it was tripping over the "Function called outside component initialization" errors.

[myieye]

I'm able to produce 3 different behaviours. I use a prod build, so that version checking is active and the script files get hashed.

1. Trigger the error without killing the server

This is done by making the script files invalid when/before the server starts = doesn't really make sense.

1) Build and run with pnpm vite build & pnpm vite preview 2) Load the home or admin dashboard page 5) Delete or rename frontend\.svelte-kit\output\client\_app\immutable\nodes\7.******.js (script file for the project page) 6) Restart the app pnpm vite preview 5) Hover over a project link and click on it 7) The desired error 🐛

2. SvelteKit automatically recovers (probably the most realistic scenario)

This is done by properly updating the app while a user has a (now outdated) loaded page.

1) Build and run with pnpm vite build & pnpm vite preview 2) Load the home or admin dashboard page 3) Make a change in [project_code]/+page.ts (e.g. add a comment) 4) Rebuild and restart the app pnpm vite build & pnpm vite preview 5) Hover over a project link 6) A 307 (404 after this PR) gets returned for a script 7) SvelteKit does a full refresh and recovers (also automatically navigating to the url behind a hovered link, which is weird, but whatever), successfully landing on the new version of the app 🪄

3. The server dies (not super interesting)

This is done by making the script files invalid while the server is running = doesn't really make sense.

1) Build and run with pnpm vite build & pnpm vite preview 2) Load the home or admin dashboard page 3) Make a change in [project_code]/+page.ts (e.g. add a comment) 4) Rebuild pnpm vite build 5) Hover over a project link 6) The server is dead 💥 with the "desired" error message 🐛

[myieye]

I just ran into this in staging again: (Including a toast: A new version of the application was detected. You may need to reload the page.")

Trace: https://ui.honeycomb.io/sil-language-forge/environments/staging/trace/iQC4TrKRxFK?fields[]=c_name&fields[]=c_service.name&span=ec384c7c42f922b5

Service version in trace: v2023-10-19-f3cf95cc Service version in app after a page reload: v2023-10-20-27ca67bf

Today is the 24th, so both versions were published several days ago. Also, it wasn't the first time I accessed the application today. WEIRD!!

So, somehow my browser loaded the version from the 19th, which wasn't functional, because the server was running the version from the 20th.

Reopening, because one way or another we have to decide if we want to deal with this more thoroughly.

[myieye]

This happened when I opened the application in a new tab. I propose that we automatically reload the page if we would land on the error page and detect a new version.

[myieye]

This hasn't been reported in staging or prod since the trace linked aboue (or since I merged my PR), so I'd say it's not very important and I'm moving to done. We'll be monitoring errors in prod anyway.

We could consider ignoring these errors in dev, where it happens frequently, almost certainly due to files being regenerated while the app is in use.

Prod:

Staging:

Dev: