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

[frederichoule]

I meant, the x-vercel-cache of your root page staging-app.usemantel.com. The main issue is that your staging-app.usemantel.com returns the HTML of an old build, so you have to find a way to invalidate the cache of that root URL.

[vecter]

I meant, the x-vercel-cache of your root page staging-app.usemantel.com. The main issue is that your staging-app.usemantel.com returns the HTML of an old build, so you have to find a way to invalidate the cache of that root URL.

Ah I see. It says MISS:

I assume that that's "right"?

[frederichoule]

Yeah it seems right - so your root page returns the correct scripts to be loaded, but those scripts don't load (example scheduler.66c77ea2.js). I can access that script from here without any problem. Can you check on your side what's the error?

[vecter]

Yeah it seems right - so your root page returns the correct scripts to be loaded, but those scripts don't load (example scheduler.66c77ea2.js). I can access that script from here without any problem. Can you check on your side what's the error?

It must be a browser caching issue. I can load that URL (https://staging-app.usemantel.com/_app/immutable/chunks/scheduler.66c77ea2.js) fine in an Incognito chrome window. However, in my main Chrome window where I've been doing all of my development work, I get the 404. I'm pretty sure it's b/c Chrome is trying to load it from the disk cache:

The Status Code shows "404 Not Found (from disk cache)". It assume it's not in the cache because it's a new file from the most recent build. I don't know why Chrome doesn't try to fetch the file remotely. Maybe because the Link: value are all relative and not absolute?

[frederichoule]

Can you adjust the Cache-control: public, immutable, max-age=31536000 header on Vercel? That means Chrome will cache the 404 pages for 365 days. It should be no-store instead. That's the root of your problem.

[vecter]

Can you adjust the Cache-control: public, immutable, max-age=31536000 header on Vercel? That means Chrome will cache the 404 pages for 365 days. It should be no-store instead. That's the root of your problem.

Thank you for that suggestion. I will look that up and try that now. Will let you know how it goes.

[vecter]

Can you adjust the Cache-control: public, immutable, max-age=31536000 header on Vercel? That means Chrome will cache the 404 pages for 365 days. It should be no-store instead. That's the root of your problem.

One thing: if I set it to no-store, wouldn't that mean that those pages are never cached? It seems that that would slow page loads significantly. Is there a better value like no-cache or something else?

[frederichoule]

You should set no-store on 404 status code only, not all of them.

• 404 status: no-store
• 200 status (root page): public, must-revalidate, max-age=86400 (although you would have to invalidate the cache on each deploy, which Vercel does by default I think)
• 200 status / immutable assets: public, immutable, max-age=31536000

[vecter]

You should set no-store on 404 status code only, not all of them.

• 404 status: no-store
• 200 status (root page): public, must-revalidate, max-age=86400 (although you would have to invalidate the cache on each deploy, which Vercel does by default I think)
• 200 status / immutable assets: public, immutable, max-age=31536000

That makes sense, thanks for spelling that out. I've scoured the Vercel docs on how to set the Cache-Control header conditioned on the response status code but I don't see how:

https://vercel.com/guides/how-to-configure-the-cache-control-response-header-in-vercel-projects#using-the-vercel.json-file https://vercel.com/docs/edge-network/headers#cache-control-header https://vercel.com/docs/projects/project-configuration#headers

Am I totally missing something or is there a simple way to do it?

[frederichoule]

I haven't played with Vercel much, so I do not know exactly how to do it. I'll give it a try later today and see what I can find. In the meantime, I also found that: https://vercel.com/docs/deployments/skew-protection.

[vecter]

I haven't played with Vercel much, so I do not know exactly how to do it. I'll give it a try later today and see what I can find. In the meantime, I also found that: https://vercel.com/docs/deployments/skew-protection.

Thanks for the reference, I'll try that and see if it resolves the issue somehow (hard to tell currently if it's exactly related)

[frederichoule]

If you find a way to no-store your 404 urls, and clear the cache on the root page on every deploy, everything will work as intended!

[vecter]

If you find a way to no-store your 404 urls, and clear the cache on the root page on every deploy, everything will work as intended!

Interesting, what do you mean by "clear the cache on the root page on every deploy"? I assume you mean the browser's cache of some files but I'm not quite sure.

[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).

Like I said here, but I do not know how to do it on Vercel. I used to have the same bug you had when I deployed our app. Our error rate was skyrocketing on each deploy, but now it's 0% since we added a clear cache step on our deploy process.

[smart]

We're running into this issue too, Vercel is aggressively caching 404s. I'm not sure how the initial 404 is happening that causes the cache hit, I'm thinking it could be a race condition with one JS file calling another before the others are on disk? I've filed a ticket with Vercel, It's not clear to me how to no-store my 404s, but still looking into it on my own.

[smart]

I've confirmed that sveltekit is not returning the Cache-Control headers on a 404 when using (my preview server locally). Vercel is caching it, which is not what Sveltekit is asking it to do. 3 days with a ticket open to Vercel and not even a first reply, opened a community issue here.

https://vercel.community/t/vercel-data-cache-404-bug/350

[smart]

Hi all, created a PR with a solution that's working for me, there are probably better approaches, but this could be a good example of the problem. https://github.com/sveltejs/kit/pull/12526