Not found /_app/immutable/assets/xxx

[kamerat]

Describe the bug

We're hosting sveltekit with SSR in a Docker container that's hosted in azure. We have datadog to track errors and we tend to see about 3 to 30 of these 404's a day on our small-medium site.

We played around with azure cdn cache, but when we enabled this, the errors really came to show, so we disabled the azure cache. When doing so, it went back to it's normal occurance.

This issue is the same as this question posted a while ago; https://github.com/sveltejs/kit/discussions/7057

Example error for a 404 asset:

Error: Not found: /_app/immutable/assets/_layout-c5c8ebf1.css
at resolve (file:///app/server/index.js:2276:18)
at resolve (file:///app/server/index.js:2163:34)
at Object.handle (file:///app/server/chunks/hooks.server.js:379:10)
at runMicrotasks (<anonymous>)
at runNextTicks (node:internal/process/task_queues:61:5)
at processImmediate (node:internal/timers:437:9)
at async respond (file:///app/server/index.js:2161:22)
at async Array.ssr (file:///app/handler-393b2283.js:1102:3)

What might be the cause of this type of error, Is it just something that happenes when document is out of sync with assets, or is it something we can do to keep this from happening?

Reproduction

-

Logs

No response

System Info

System:
    OS: macOS 12.5.1
    CPU: (8) arm64 Apple M1
    Memory: 347.42 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.15.1 - /usr/local/bin/node
    npm: 8.11.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 110.0.5481.100
    Safari: 15.6.1
  npmPackages:
    @sveltejs/adapter-node: next => 1.0.0-next.85 
    @sveltejs/kit: ^1.0.1 => 1.0.1 
    svelte: ^3.44.0 => 3.55.0 
    vite: ^4.0.3 => 4.0.3

Severity

annoyance

Additional Information

No response

[dummdidumm]

My guess: You deploy a new version, the user is still using the old version and doing a navigation to a not-yet-loaded page where they need to request an asset (JS file or whatever), which then fails. It's more visible when turning CDN off since the CDN is caching the outdated assets from your previous deployment for a while. SvelteKit should do a full-page reload if it sees that a navigation wasn't successful. I'm not sure if this also applies to CSS files though.

[Conduitry]

I think it is JS files only, but that's fine since any pages that are loaded for client-side nav also have a JS portion. When one of these requests fails with a 404, SvelteKit will automatically request /_app/version.json, and if that's change, it will turn the navigation into a full page reload rather that a client-side SPA navigation.

[Rich-Harris]

Something we should document: you can detect version changes and proactively opt in to full page reloads by setting a version.pollInterval in your config and using it to disable the client-side router:

<!-- src/routes/+layout.svelte -->
<script>
  import { updated } from '$app/stores';
</script>

<main data-sveltekit-reload={$updated ? '' : 'off'}>
  <slot />
</main>

[snuffyDev]

@Rich-Harris https://github.com/sveltejs/kit/issues/9089#issuecomment-1435370289

Firstly, excuse me for my ignorance, but I've been getting similar errors on Sentry for an app at work, and I've been tasked with investigating it (3 weeks in, currently writing a 3rd Notion document :face_exhaling:). Seeing your response gave me a few questions about this.

The docs for the updated config option currently states:

Not all navigations will result in an error though, for example if the JavaScript for the next page is already loaded.

1. Would a pre-rendered SPA (using static adapter) potentially be one of the cases where a navigation wouldn't trigger a full-page reload?
2. Would it be safe to assume that Sentry (and similar platforms) would be reporting a lot of false positives?
   • Example: User is on https://my-fake.app/, they navigate to https://my-fake.app/profile. Although the page loads perfectly fine, Sentry still reports that there was an error.

I appreciate any insight, and if this wasn't the appropriate place to ask, I can create a Discussion. This potentially could save me a lot of time, thank you!

[dummdidumm]

1. Not necessarily. If some assets are not loaded yet, and they are required for the next page you're about to navigate to, you'll also run into the 404 in case of a new version
2. Yes, everytime you deploy a new version you'll likely get some false positives in the sense that there are errors reported but your users likely won't notice anything

[kristjanmar]

I think the built-in functionality for detecting an app update and switching to a full page reload may be unreliable in some cases.

When the user gets a 404 on one of the chunks to be imported, I can see the call for __version.json but the user still goes to an error page when clicking on the link.

I can see the errors in Sentry and I can confirm via Session Replay that the error page +error.svelte is indeed showing to the user instead of the page that the user wanted to navigate to. So it's not a false positive error report.

This appears to happen randomly and I am unable to replicate it myself. But it's definitely happening for some users.

The error is usually "Importing a module script failed" or "Failed to fetch dynamically imported module" -- so perhaps the client is still trying to load one of the files from the previous release?

[Rich-Harris]

That's odd — those are the errors that usually lead to a request for version.json followed by a reload. Unless version.json is somehow the same before and after the redeploy?

[kevinrenskers]

Something we should document: you can detect version changes and proactively opt in to full page reloads by setting a version.pollInterval in your config and using it to disable the client-side router:

<!-- src/routes/+layout.svelte -->
<script>
  import { updated } from '$app/stores';
</script>

<main data-sveltekit-reload={$updated ? '' : 'off'}>
  <slot />
</main>

I'm also trying to solve the extremely common Failed to fetch dynamically imported module error and came across this issue, and this comment from @Rich-Harris. Sadly using this code I get the following error in my console:

Error: Cannot subscribe to 'updated' store on the server outside of a Svelte component, as it is bound to the current request via component context. This prevents state from leaking between users.For more information, see https://kit.svelte.dev/docs/state-management#avoid-shared-state-on-the-server

Looking at https://kit.svelte.dev/docs/modules#$app-stores-updated it didn't really make it clearer to me how to use this properly.

[dummdidumm]

I don't get this error given that code snippet. Please open a separate issue with a reproduction repo if the issue persists.

[kevinrenskers]

I haven't seen it anymore after that one time, no idea what caused it 🤷‍♂️

[vettloffah]

That's odd — those are the errors that usually lead to a request for version.json followed by a reload. Unless version.json is somehow the same before and after the redeploy?

We are getting this error on our site hosted on Vercel. I've had two separate people report that they are getting a 404 error, even after refreshing the page. And the error in the console looks like this:

If they open an incognito window, it loads fine. So I assume they have an old tab open like mentioned above.

We have a webhook automatically re-deploying the branch on vercel after a few different events, such as updating a product in our ecommerce store, inventory stock level updates, or editing one of our marketing pages. I would say on average it is re-deployed once 30 minutes - 1 hour.

Is it likely that the version.json doesn't get updated in this context?

CC @Rich-Harris

[magic-thomas]

Same error here.

package versions..

├── @sveltejs/adapter-node@1.2.3 ├── @sveltejs/kit@1.13.0 ├── svelte-check@3.1.4 ├── svelte@3.57.0

[magic-thomas]

Something we should document: you can detect version changes and proactively opt in to full page reloads by setting a version.pollInterval in your config and using it to disable the client-side router:

<!-- src/routes/+layout.svelte -->
<script>
  import { updated } from '$app/stores';
</script>

<main data-sveltekit-reload={$updated ? '' : 'off'}>
  <slot />
</main>

After following this, I got errors from all js file.

So I made trick. I exchanged two values.

<main data-sveltekit-reload={$updated ? 'off' : ''}>

But it showed same results.

I don't have deep knowledge, so just wish somebody can solve this issue.

[snuffyDev]

Just figured out what exactly is changing, all of the files Kit (or Vite, most likely) touches / creates always have a different hash, regardless of if Vite's hashes would stay the same. Here's a commit on a repro -> https://github.com/snuffyDev/sveltekit-hash-gen-repro/commit/0343f726a29ddda16263b1e938be3d0adcab8301

To reproduce yourself locally:

• clone and install.
• run a build (save the contents of the singletones.xxxx.js file, for example, somehow)
• run a build again
• diff the two singleton files.

The hashes change, and even the actual output does as well, even though the contents haven't? Is due to Vite building with rollup, or something?

Here's a video showing what Vite's behavior looks like when building a library I work on (contents of the files haven't changed between builds -> hashes stay the same):

https://user-images.githubusercontent.com/72365477/236735437-3ccbe3b6-5b84-435f-88f7-fc8bc172e3eb.mp4

[gtm-nayan]

@snuffyDev Are you setting a version name explicitly in your svelte config? Otherwise it defaults to the timestamp and as such every build will have a different version number embedded in it which will change the hashes for most chunks.

[snuffyDev]

@snuffyDev Are you setting a version name explicitly in your svelte config? Otherwise it defaults to the timestamp and as such every build will have a different version number embedded in it which will change the hashes for most chunks.

Midnight Airhead moment :skull:, slipped my mind that version.name existed.

[wobedi]

@gtm-nayan Assuming default svelte version.name config (i.e. timestamp of build), is it therefore intended that the hashes for most chunks change on every deploy, regardless of code changes? Because that seems to lead to "overeager invalidation" and thus to more "user agent tries to fetch invalidated chunk and crashes" issues? Or am I missing something?

[gtm-nayan]

is it therefore intended that the hashes for most chunks change on every deploy, regardless of code changes?

We certainly don't want that to happen, but I don't really see any other sane default that we can put either. We're assuming people won't usually deploy often without code changes. (css, js, even strings inside your js/svelte files are code changes).

user agent tries to fetch invalidated chunk and crashes

The router regularly polls the version file to check if it has been updated and falls back to native navigation if it has. And you can use the snippet that Rich provided above in case you make use of a lot of dynamic imports. https://github.com/sveltejs/kit/blob/51c0b3cdccf3545892459f196bc71740481bcff8/packages/kit/src/runtime/client/client.js#L735

Users should probably base their versions on some version control identifier if available but the framework can't assume its presence.

We could maybe try to use a hash of the vite manifest, but that has a chicken and egg problem of its own.

[Fasteroid]

I get this without fail every time for github pages. Why?

[SubhamPramanik]

Hey folks. We're facing this issue as well. Somehow it's originating from Sentry. Is there a workaround for this? Some of our users are affected.

[eltigerchino]

@Fasteroid @SubhamPramanik if you can share a reproduction, it would help with diagnosing the issue.

[jycouet]

@SubhamPramanik , what version are you running would help as well.

[tiwarishankar]

hey @jycouet right now we are using "@sveltejs/kit": "^1.20.5", and error that is coming for us is attached below @SubhamPramanik

[SubhamPramanik]

@jycouet @eltigerchino We aren't able to fully reproduce the issue at will on our side. It happens pretty randomly and we can see the same in user session replays as well. Here are some pointers that might be relevant, as this issue started happening after we made the following changes:

• We recently moved our Sveltekit app to a Docker container. I've shared the Dockerfile [1] for it below.
• We were running the app as vite dev --host but now we're running it as node build/index.js after vite build.
• I'm not sure if this is relevant but with vite dev --host I saw significant memory consumption in the pod and the app would crash pretty frequently, which led us to use node build/index.js, post which the resource consumption wasn't as much.
• Also sharing our package.json [2] for version checks and dependencies.
• The issue gets resolved as soon as we clear the cache. So I'm assuming the issue is somewhat related to cache reference.

[1] Dockerfile

# Build Stage
FROM node:18-buster AS build

# Install Doppler
ARG DOPPLER_AUTH_TOKEN
ARG DOPPLER_CONFIG
ENV DOPPLER_TOKEN ${DOPPLER_AUTH_TOKEN}
ENV DOPPLER_CONFIG ${DOPPLER_CONFIG}

RUN apt-get update && apt-get install -y apt-transport-https ca-certificates curl gnupg && \
    curl -sLf --retry 3 --tlsv1.2 --proto "=https" 'https://packages.doppler.com/public/cli/gpg.DE2A7741A397C129.key' | apt-key add - && \
    echo "deb https://packages.doppler.com/public/cli/deb/debian any-version main" | tee /etc/apt/sources.list.d/doppler-cli.list && \
    apt-get update && \
    apt-get -y install doppler

WORKDIR /app
COPY . .
RUN doppler setup -p forntend_app --config $DOPPLER_CONFIG

# Install Python, make, and g++ for node-gyp
RUN apt-get install -y python3 make g++ && ln -sf python3 /usr/bin/python

# Install dependencies
RUN npm install

# Build the package
RUN npm run build

# Expose port
EXPOSE 5173
EXPOSE 3000

CMD ["npm", "run", "prod"]

[2] package.json

{
  "name": "frontend_app",
  "private": "true",
  "version": "0.0.1",
  "scripts": {
    "dev": "doppler secrets download --no-file --format env > .env && vite dev --host",
    "build": "doppler secrets download --no-file --format env > .env &&  vite build",
    "preview": "vite preview --port 3000",
    "check": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json",
    "check:watch": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json --watch",
    "generate:sitemap": "node generate-sitemap.js",
    "prod": "doppler secrets download --no-file --format env > .env && node build/index.js"
  },
  "devDependencies": {
    "@lottiefiles/svelte-lottie-player": "^0.3.0",
    "@neoconfetti/svelte": "^1.0.0",
    "@sveltejs/adapter-auto": "^2.0.0",
    "@sveltejs/kit": "^1.20.5",
    "@sveltestack/svelte-query": "^1.6.0",
    "@tsconfig/svelte": "^4.0.1",
    "@types/cookie": "^0.5.1",
    "@types/gtag.js": "^0.0.13",
    "@types/js-cookie": "^3.0.3",
    "autoprefixer": "^10.4.14",
    "axios": "^1.4.0",
    "dotenv": "^16.1.4",
    "linkifyjs": "^4.1.1",
    "node-sass": "^8.0.0",
    "postcss": "^8.4.23",
    "postcss-load-config": "^4.0.1",
    "prismjs": "^1.29.0",
    "socket.io-client": "^4.6.1",
    "svelte": "^4.0.0",
    "svelte-check": "^3.4.3",
    "svelte-intersection-observer": "^0.10.0",
    "svelte-preprocess": "^5.0.3",
    "svelte-transition": "^0.0.7",
    "tailwindcss": "^3.3.1",
    "tslib": "^2.4.1",
    "typescript": "^5.0.0",
    "vite": "^4.3.6"
  },
  "type": "module",
  "dependencies": {
    "@sentry/sveltekit": "^7.69.0",
    "@sveltejs/adapter-node": "^1.3.1",
    "dom-to-image": "^2.6.0",
    "downloadjs": "^1.4.7",
    "file-saver": "^2.0.5",
    "html-to-image": "^1.11.11",
    "html2canvas": "^1.4.1",
    "js-cookie": "^3.0.5",
    "modern-screenshot": "^4.4.28",
    "moment": "^2.29.4",
    "noisejs": "^2.1.0",
    "path": "^0.12.7",
    "sass": "^1.63.6",
    "sitemap": "^7.1.1",
    "statsig-js": "^4.39.2",
    "svelte-click-outside": "^1.0.0",
    "svelte-french-toast": "^1.2.0",
    "svelte-infinite-scroll": "^2.0.1",
    "three": "^0.154.0",
    "troika-three-text": "^0.48.0-unicode.3",
    "uuid": "^9.0.0",
    "vite-plugin-string": "^1.2.1"
  }
}

[eltigerchino]

@SubhamPramanik thank you for sharing that info. Is it possible for you to also share what files are being cached / how the cache is setup? This seems to be a common factor with regards to the issue author's description

[Fasteroid]

Thank you for re-opening. The only reason I'm here is because nobody has answered #9381, so I'm forced to use CSR just to have client-side javascript.

After clearing my head for 2 weeks, I realize now the issue is that since I'm hosting on Github Pages but using the legacy way of deploying a branch, SvelteKit's guess that the chunks are at https://github.com/Fasteroid/svelte-portfolio/ is wrong; they're actually at https://github.com/Fasteroid/svelte-portfolio/tree/gh-pages.

Seems this was likely developer error on my part. What's the correct way to fix this?

[eltigerchino]

After clearing my head for 2 weeks, I realize now the issue is that since I'm hosting on Github Pages but using the legacy way of deploying a branch, SvelteKit's guess that the chunks are at https://github.com/Fasteroid/svelte-portfolio/ is wrong; they're actually at https://github.com/Fasteroid/svelte-portfolio/tree/gh-pages.

Seems this was likely developer error on my part. What's the correct way to fix this?

@Fasteroid You’ll want to configure the paths.base setting to match wherever your files live at.

https://kit.svelte.dev/docs/configuration#paths

See https://kit.svelte.dev/docs/adapter-static#github-pages for more comprehensive info. I’ve just updated it.

[SubhamPramanik]

Hey @eltigerchino, I looked into our setup and I don't see any caching config on our side. My best guess would be that we're using the default caching setup provided by Vite/SvelteKit.

Here in the vite.config.ts:

import { sveltekit } from "@sveltejs/kit/vite";
import { defineConfig, loadEnv } from "vite";
import string from "vite-plugin-string";
import { sentrySvelteKit } from '@sentry/sveltekit'

export default ({ mode }: any) => {
  // Load app-level env vars to node-level env vars.
  process.env = { ...process.env, ...loadEnv(mode, process.cwd()) };

  return defineConfig({
    resolve: {
      alias: {
        $components: "/src/lib/components",
        $helpers: "/src/lib/helpers",
        $assets: "/src/lib/assets",
        $pages: "/src/lib/pages",
        $apis: "/src/lib/apis",
        $stores: "/src/lib/stores",
        $context: "/src/lib/context",
      },
    },
    plugins: [sentrySvelteKit({
      sourceMapsUploadOptions: {
        org: 'xxxxxxx',
        project: 'xxxxxxx',
      }
    }), sveltekit(), string({ include: "**/*.glsl" })],
  });
};

Something to note, we've CloudFlare proxy siting infront of all the requests.

[eltigerchino]

Hey @eltigerchino, I looked into our setup and I don't see any caching config on our side. My best guess would be that we're using the default caching setup provided by Vite/SvelteKit.

Something to note, we've CloudFlare proxy siting infront of all the requests.

@SubhamPramanik could you check the response headers of /_app/version.json in your production environment? I'm wondering if it's possible that it's getting cached somehow. I'm likely wrong about this but anything's worth a shot at this point.

The node adapter currently sets cache headers for /_app/immutable/*. Maybe we should also explicitly add a no-cache header or the like for version.json?

https://github.com/sveltejs/kit/blob/ce4fd764e271b1a461979dfaf9698af6f36e3714/packages/adapter-node/src/handler.js#L39-L42

[SubhamPramanik]

@eltigerchino Surprisingly enough I don't see a call to /_app/version.json in the network logs in the browser.

But here is the response header for general /_app/immutable/* calls.

Our app is open to the public: https://chat.collectivai.com, incase you want to try things out.

[YankeeTube]

lol

[quadroloop]

To anyone that still has this issue, tried everything in this thread but nothing works, I just want to share a solution that might help:

Solution that worked for me: Clearing the Cached images and files in Chrome settings: Goto: chrome://settings/clearBrowserData?search=clear

I only left the images and files option checked because i don't want to delete all browsing data in that chrome profile. After clearing the cache the site works as normal.

My case:

• OS: Mac OS ventura
• Sveltekit: 1.27.6
• Hosted on Vercel

Other notes: This error just came out of nowhere for me, I deploy changes to a branch Vercel deployment is fine and the error just appeared, and only on one chrome browser, testing on other browser my site works fine, it even works on incognito. But the errors persist on the regular chrome profile

Hope this helps, Cheers!

[YankeeTube]

To anyone that still has this issue, tried everything in this thread but nothing works, I just want to share a solution that might help:

Solution that worked for me: Clearing the Cached images and files in Chrome settings: Goto: chrome://settings/clearBrowserData?search=clear

I only left the images and files option checked because i don't want to delete all browsing data in that chrome profile. After clearing the cache the site works as normal.

My case:

• OS: Mac OS ventura
• Sveltekit: 1.27.6
• Hosted on Vercel

Other notes: This error just came out of nowhere for me, I deploy changes to a branch Vercel deployment is fine and the error just appeared, and only on one chrome browser, testing on other browser my site works fine, it even works on incognito. But the errors persist on the regular chrome profile

Hope this helps, Cheers!

It may be useful in developing situations, but this error appears in users after production. Therefore, it is not very helpful.

[eunukasiko]

Ditto, it only appears in deployment for us too (with adapter-node).

[younghu-lee]

This issue occur building files name change. so, i fixed does not change file name with hash. In this file line 638~640, building file name with hash so i remove hash. and not occur this issue. node_modules modify with 'patch-package'.

[elucidsoft]

I have this problem as well, it's really bad actually. Here are some interesting observations. I am using Cloudflare Pages, and I noticed if you disable proxying entirely (meaning no cache of any kind is being applied by a cdn, it all seems to work). Add proxy back (everything gets cached by cdn) it all breaks again. Even if I clear the CDN cache, it's still broken. Adding the version check stuff did not resolve the issue at all. Going to the root of the app always works. If you load the initial page from root, everything works, every single time even with CDN cache on. If you go to a non-root page, it's a gamble if it will work or not. Some work, some don't and it appears to be completely random. Sometimes its trying to pull js files that simply don't exist in the deployment and were from previous deployments. Where is getting the reference to these? I have no idea as I am using an Incognito Window and I have cleared the CDN cache. So it really shouldn't have a reference to these old paths, but somehow it does. It's possible some kind of caching header is really screwing things up somewhere as CDN's use edge caches as well and it's possible it's cached somewhere else along the route even if cleared? It's very odd. It's not just js files though, it's also css files. Pretty much anything inside of immutable gets completely botched with a CDN enabled.

I was originally thinking it was related to Cloudflare Pages or the Adapter but since it works 100% fine if you disable the CDN I am not so sure. I have not tried uploading to another hosting provider, but based on what I saw in here it doesn't look like it would help.

[elucidsoft]

Would like to add a new discovery to this, if you enabled Signed Exchanges in Cloudflare and your clicking on the links in Google Search Results to test this behavior as I was since that's where the majority of complaints were coming from, those links are not pointing to your site. They are pointing to a Cached version of your page on Google Exchange and this completely breaks SvelteKit for some reason, so you cannot use this feature with SvelteKit. You will need to disable this and then wait several days, weeks maybe for Google to drop your site from the Google Exchange network.

[younghu-lee]

Hi guys. I found a way fully handle this. first, you see this my reply

First way

In addition, i remove immutable cash line by using patch-package. So, not occur this situation. But, sveltekit developer tell me, this way is page loading speed down. So, you guys remind this.

[frederichoule]

This is causing a lot of issues on my end on each new version deploy. Setting the poll interval lower would probably help, but that means an extra few million monthly hits to handle (and to pay for, considering Cloudflare Pages pricing for example). I'm trying a lot of hacky things, but nothing works flawlessly yet.

[based64-eth]

I'm confused why this is still an issue, and why it is not fixed at the vite or sveltekit layer.

It seems like maaaany more people should be encountering this issue.

[frederichoule]

I was able to mostly fix the issue on my side. I'm using CloudFlare Pages, and whenever I deploy a new version I just purge the cache for the entire domain using the CloudFlare API. Doing this fix the issue for all new users arriving on the app, and then the pollInterval takes care of the users already on the app.

[michaelchen01]

I'm also experiencing something similar. I'm deployed on Vercel using the vercel adapter. The initial SSR'd HTML loads correctly, but when we try to fetch the JS chunks, the browser decides to try to fetch them from the disk cache instead of loading fresh chunks, which causes unexpected behavior.

I've tried:

• setting a deterministic version name in svelte.config.js
• followed these instructions to track updates https://kit.svelte.dev/docs/configuration#version

I've noticed that version.json isn't even called as network event sometimes - I wonder if that's b/c the JS needed to do so isn't loaded properly?

Thanks!

[eugenechantk]

I am still experiencing the same problem after I:

1. set the version.pollInterval to 6000
2. set the version name as my commit hash

But some people still have the not found error. Anyone figured out a reliable solution?

[vecter]

I'm having the same issue also and have tried everything under the sun related to https://kit.svelte.dev/docs/configuration#version to try to resolve this. Any ideas?

[frederichoule]

If you clear your app's cache on each deploy, it works flawlessly. For example, on CloudFlare, use Caching -> Configuration -> Purge everything (or Custom purge).

[vecter]

If you clear your app's cache on each deploy, it works flawlessly. For example, on CloudFlare, use Caching -> Configuration -> Purge everything (or Custom purge).

We're using Vercel without CloudFlare. Not sure if there's anything we can do with this setup to clear the app cache.

[DigitallyTailored]

Did you guys just have this happen on a site too? I did as well for one also running through cloudflare as a dns and cache provider. Wondering if their cache maybe had a minute

[vecter]

I've noticed that version.json isn't even called as network event sometimes - I wonder if that's b/c the JS needed to do so isn't loaded properly?

Yes, that may be the case. For example, in addition to a litany or 404s for a bunch of files, including

GET https://staging-app.usemantel.com/_app/immutable/entry/app.e6f98f24.js net::ERR_ABORTED 404 (Not Found)

...

TypeError: Failed to fetch dynamically imported module: https://staging-app.usemantel.com/_app/immutable/entry/start.3303bec4.js

The app's JS never loads. When I inspect the DOM, the only thing inside the body > div is the load script, which contains at the bottom:

Promise.all([
    import("./_app/immutable/entry/start.3303bec4.js"),
    import("./_app/immutable/entry/app.f7e92c3b.js")
]).then(([kit, app]) => {
    kit.start(app, element);
});

There is no further HTML loaded from the root layout, etc. As you can see, the cached version is looking for app.e6f98f24.js but the newest version is ap.f7e92c3b.js.

[frederichoule]

@vecter - what does your x-vercel-cache header look like? By reading the docs, it seems that Vercel is suppose to clear the cache on every deploy. More infos here: https://vercel.com/docs/edge-network/caching

[vecter]

@frederichoule

It says either HIT or MISS depending on whether or not it can find the file. Apologies for my noobie question but how does that relate to this issue?

I did a hard purge of the Vercel app's data cache but that didn't do anything.