Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kamerat opened this issue Feb 17, 2023 · 64 comments
Open

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

kamerat opened this issue Feb 17, 2023 · 64 comments

Comments

@kamerat
Copy link
Contributor

kamerat commented Feb 17, 2023

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?

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

@dummdidumm
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link

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

  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
Copy link
Member

  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
Copy link

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
Copy link
Member

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

This comment has been minimized.

@dummdidumm

This comment has been minimized.

@kevinrenskers

This comment has been minimized.

@vettloffah
Copy link

vettloffah commented Apr 20, 2023

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

@magic-thomas
Copy link

magic-thomas commented Apr 23, 2023

Same error here.

Screen Shot 2023-04-24 at 1 18 00 AM

package versions..

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

@magic-thomas
Copy link

magic-thomas commented Apr 23, 2023

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.

Screen Shot 2023-04-24 at 1 50 40 AM

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
Copy link

snuffyDev commented May 8, 2023

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
Copy link
Contributor

@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
Copy link

@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
Copy link

wobedi commented May 9, 2023

@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
Copy link
Contributor

gtm-nayan commented May 10, 2023

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.

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.

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

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

@SubhamPramanik
Copy link

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
Copy link
Member

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

@jycouet
Copy link
Contributor

jycouet commented Oct 31, 2023

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

@tiwarishankar
Copy link

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

@SubhamPramanik
Copy link

SubhamPramanik commented Nov 1, 2023

@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
Copy link
Member

@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

This comment was marked as off-topic.

@elucidsoft
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

frederichoule commented Apr 28, 2024

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
Copy link

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:

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
Copy link

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

frederichoule commented Jul 8, 2024

@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
Copy link

vecter commented Jul 8, 2024

@frederichoule

image

image

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
Copy link

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
Copy link

vecter commented Jul 8, 2024

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:

image

I assume that that's "right"?

@frederichoule
Copy link

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?

CleanShot 2024-07-08 at 09 01 45@2x

@vecter
Copy link

vecter commented Jul 8, 2024

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?

CleanShot 2024-07-08 at 09 01 45@2x

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:

image

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
Copy link

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

frederichoule commented Jul 8, 2024

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

frederichoule commented Jul 8, 2024

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

frederichoule commented Jul 8, 2024

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
Copy link

vecter commented Jul 8, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests