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?
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
- chore: add fix suggested in https://github.com/sveltejs/kit/issues/9089 — committed to mandrasch/sveltekit-mittwald-spaceserver-demo by mandrasch a year ago
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.
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
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
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.
It may be useful in developing situations, but this error appears in users after production. Therefore, it is not very helpful.
lol
@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 ano-cache
header or the like forversion.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:
vite dev --host
but now we’re running it asnode build/index.js
aftervite build
.vite dev --host
I saw significant memory consumption in the pod and the app would crash pretty frequently, which led us to usenode build/index.js
, post which the resource consumption wasn’t as much.[1] Dockerfile
[2] package.json
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: