Not found /_app/immutable/assets/xxx #9089

kamerat · 2023-02-17T11:47:29Z

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; #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

The text was updated successfully, but these errors were encountered:

dummdidumm · 2023-02-17T11:52:55Z

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 · 2023-02-17T13:04:55Z

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 · 2023-02-17T22:54:27Z

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 · 2023-02-18T05:20:19Z

@Rich-Harris #9089 (comment)

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 😮‍💨). 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.

Would a pre-rendered SPA (using static adapter) potentially be one of the cases where a navigation wouldn't trigger a full-page reload?
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 · 2023-02-18T08:40:25Z

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
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 · 2023-02-20T13:39:54Z

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 · 2023-03-02T23:08:25Z

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?

vettloffah · 2023-04-20T17:48:34Z

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 · 2023-04-23T16:23:35Z

Same error here.

package versions..

├── @sveltejs/[email protected]
├── @sveltejs/[email protected]
├── [email protected]
├── [email protected]

magic-thomas · 2023-04-23T17:04:43Z

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:

<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 · 2023-05-08T04:42:18Z

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 -> snuffyDev/sveltekit-hash-gen-repro@0343f72

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):

2023-05-07-23-06-36.mp4

gtm-nayan · 2023-05-08T04:47:28Z

@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 · 2023-05-08T11:06:44Z

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

wobedi · 2023-05-09T17:24:10Z

@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 · 2023-05-10T00:30:32Z

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.

kit/packages/kit/src/runtime/client/client.js

Line 735 in 51c0b3c

return await native_navigation(url);

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 · 2023-10-19T07:52:16Z

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

SubhamPramanik · 2023-10-31T13:49:09Z

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 · 2023-10-31T16:53:09Z

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

jycouet · 2023-10-31T19:04:38Z

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

tiwarishankar · 2023-11-01T10:00:00Z

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

SubhamPramanik · 2023-11-01T10:14:42Z

@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 · 2023-11-01T11:09:29Z

@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

DigitallyTailored · 2024-07-08T15:25:26Z

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 · 2024-07-08T15:42:40Z

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 · 2024-07-08T15:45:29Z

@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 · 2024-07-08T15:48:32Z

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

frederichoule · 2024-07-08T15:51:12Z

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 · 2024-07-08T15:55:51Z

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 · 2024-07-08T16:02:23Z

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 · 2024-07-08T16:08:53Z

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 · 2024-07-08T16:14:39Z

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 · 2024-07-08T16:17:30Z

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 · 2024-07-08T16:28:54Z

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 · 2024-07-08T16:33:21Z

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 · 2024-07-08T16:44:12Z

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 · 2024-07-08T17:30:35Z

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 · 2024-07-08T19:19:32Z

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 · 2024-07-08T19:22:07Z

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 · 2024-07-08T19:30:05Z

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 · 2024-07-08T19:33:59Z

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 · 2024-07-26T19:28:40Z

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 · 2024-07-29T17:22:39Z

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 · 2024-07-31T17:03:01Z

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. #12526

Some adapters (like Vercel) apply a immutable cache header by default to static assets. They respect explicitly set headers though. Therefore apply a "must immediately revalidate" cache header to the 404 response of static assets in the SvelteKit runtime related to #9089

* fix: set revalidate cache header on 404'd static assets Some adapters (like Vercel) apply a immutable cache header by default to static assets. They respect explicitly set headers though. Therefore apply a "must immediately revalidate" cache header to the 404 response of static assets in the SvelteKit runtime related to #9089 * Update packages/kit/src/runtime/server/respond.js Co-authored-by: Conduitry <[email protected]> --------- Co-authored-by: Conduitry <[email protected]>

alexbjorlig · 2024-10-15T15:11:42Z

I can reproduce this issue now, depoyed on Vercel (and even with skew protection enabled).

Repo is here.

To reproduce, check out this video I recorded.

But essentially you have to:

Visit the deployed page
Add a code-change, bump the version and deploy
In another tab visit the site
Go back to the old tab and inspect how it's getting 404

eltigerchino · 2024-10-17T02:13:33Z

I can reproduce this issue now, depoyed on Vercel (and even with skew protection enabled).

Repo is here.

To reproduce, check out this video I recorded.

But essentially you have to:

Visit the deployed page

Add a code-change, bump the version and deploy

In another tab visit the site

Go back to the old tab and inspect how it's getting 404

Hi @alexbjorlig , thank you for the detailed video, it's really helpful. I don't currently have access to skew protection so I can't reproduce this but I'll forward the matter to @Rich-Harris @dummdidumm @trueadm who can look at it when they have some free time.

Like you said in the video, it's probably the new tab which is updating the cookie and causing the old tab to lose the correct cookie. I'd recommend creating a new issue for this.

You may also be interested in this issue #12592 which advocates for using a header instead of a cookie.

museadam · 2024-10-19T00:43:31Z

I had this same problem on some dynamic routes and I fixed it by adding a +page.ts file to the effected routes with this code in it:

export const ssr = false;

https://kit.svelte.dev/docs/page-options#ssr

cdemi mentioned this issue Mar 10, 2023

adapter-node sends cache headers when static files are 404 #9393

Closed

This comment has been minimized.

Sign in to view

kevinrenskers mentioned this issue Mar 27, 2023

try/catch fetching the version.json file #9526

Closed

migbash mentioned this issue Apr 25, 2023

🔥 Google unable to index pages Betarena/scores#1231

Closed

mandrasch added a commit to mandrasch/sveltekit-mittwald-spaceserver-demo that referenced this issue May 10, 2023

chore: add fix suggested in sveltejs/kit#9089

637215e

This comment was marked as off-topic.

Sign in to view

smart mentioned this issue Jul 31, 2024

Disable caching of 404s for immutable assets in vercel-adapter #12526

Closed

6 tasks

dummdidumm mentioned this issue Aug 1, 2024

fix: set revalidate cache header on 404'd static assets #12530

Merged

6 tasks

eltigerchino mentioned this issue Oct 16, 2024

Hooking into asset serving to avoid 404 #12815

Open

eltigerchino mentioned this issue Oct 17, 2024

Why is __vdpl cookie used for Skew Protection in Vercel instead of x-deployment-id header? #12592

Open

Not found /_app/immutable/assets/xxx #9089

Not found /_app/immutable/assets/xxx #9089

Comments

kamerat commented Feb 17, 2023

Describe the bug

Reproduction

Logs

System Info

Severity

Additional Information

dummdidumm commented Feb 17, 2023

Conduitry commented Feb 17, 2023

Rich-Harris commented Feb 17, 2023

snuffyDev commented Feb 18, 2023

dummdidumm commented Feb 18, 2023

kristjanmar commented Feb 20, 2023

Rich-Harris commented Mar 2, 2023

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

vettloffah commented Apr 20, 2023 • edited Loading

magic-thomas commented Apr 23, 2023 • edited Loading

magic-thomas commented Apr 23, 2023 • edited Loading

snuffyDev commented May 8, 2023 • edited Loading

gtm-nayan commented May 8, 2023

snuffyDev commented May 8, 2023

wobedi commented May 9, 2023

gtm-nayan commented May 10, 2023 • edited Loading

Fasteroid commented Oct 19, 2023

SubhamPramanik commented Oct 31, 2023

eltigerchino commented Oct 31, 2023

jycouet commented Oct 31, 2023

tiwarishankar commented Nov 1, 2023

SubhamPramanik commented Nov 1, 2023 • edited Loading

eltigerchino commented Nov 1, 2023

This comment was marked as off-topic.

DigitallyTailored commented Jul 8, 2024

vecter commented Jul 8, 2024

frederichoule commented Jul 8, 2024 • edited Loading

vecter commented Jul 8, 2024

frederichoule commented Jul 8, 2024

vecter commented Jul 8, 2024

frederichoule commented Jul 8, 2024

vecter commented Jul 8, 2024 • edited Loading

frederichoule commented Jul 8, 2024

vecter commented Jul 8, 2024

vecter commented Jul 8, 2024

frederichoule commented Jul 8, 2024 • edited Loading

vecter commented Jul 8, 2024 • edited Loading

frederichoule commented Jul 8, 2024 • edited Loading

vecter commented Jul 8, 2024

frederichoule commented Jul 8, 2024 • edited Loading

vecter commented Jul 8, 2024

frederichoule commented Jul 8, 2024

smart commented Jul 26, 2024

smart commented Jul 29, 2024 • edited Loading

smart commented Jul 31, 2024

alexbjorlig commented Oct 15, 2024 • edited Loading

eltigerchino commented Oct 17, 2024 • edited Loading

museadam commented Oct 19, 2024

vettloffah commented Apr 20, 2023 •

edited

Loading

magic-thomas commented Apr 23, 2023 •

edited

Loading

magic-thomas commented Apr 23, 2023 •

edited

Loading

snuffyDev commented May 8, 2023 •

edited

Loading

gtm-nayan commented May 10, 2023 •

edited

Loading

SubhamPramanik commented Nov 1, 2023 •

edited

Loading

frederichoule commented Jul 8, 2024 •

edited

Loading

vecter commented Jul 8, 2024 •

edited

Loading

frederichoule commented Jul 8, 2024 •

edited

Loading

vecter commented Jul 8, 2024 •

edited

Loading

frederichoule commented Jul 8, 2024 •

edited

Loading

frederichoule commented Jul 8, 2024 •

edited

Loading

smart commented Jul 29, 2024 •

edited

Loading

alexbjorlig commented Oct 15, 2024 •

edited

Loading

eltigerchino commented Oct 17, 2024 •

edited

Loading