kit: Not found /_app/immutable/assets/xxx

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?

Screen Shot 2023-02-17 at 12 36 28 PM

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

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 14
  • Comments: 41 (13 by maintainers)

Commits related to this issue

Most upvoted comments

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?

This issue occur building files name change. so, i fixed does not change file name with hash. image 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’.

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

Screenshot 2023-11-01 at 3 29 29 PM

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:

image

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

  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

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.

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.

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.

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.

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 image

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.

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

@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"
  }
}

@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 💀, slipped my mind that version.name existed.

@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.

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>