Hooking into asset serving to avoid 404

[andersekdahl]

Describe the problem

From what I know it's not possible to hook into the serving of build artifacts in the _app folder. The biggest use case I have for it is to be able to hook into it to prevent 404s on assets that no longer exists which is an issue during deployment where clients are still on the "old" version in their browser.

Another use case is being able to have middlewares for the build artifact files to set custom headers, but that's a lot less important.

Describe the proposed solution

Some way of registering a 404 handler for the _app folder or some sort of middleware where I would be able to detect a 404 and prevent it from really becoming a 404.

Alternatives considered

I'm not aware of a way to solve this except perhaps building my own Sveltekit adapter which feels overkill for this.

Importance

would make my life easier

Additional Information

No response

[Conduitry]

Prevent 404s in what way? What would you return instead?

There are built-in mechanisms for dealing with this version skew issue. Have you looked into those and decided they are insufficient?

[andersekdahl]

Prevent 404s in what way? What would you return instead?

By storing old build artifacts in some external storage and fetching it from there in the 404 handler.

There are built-in mechanisms for dealing with this version skew issue. Have you looked into those and decided they are insufficient?

From what I know that only applies if you use Vercel to host the site? Or am I missing something?

[teemingc]

There are built-in mechanisms for dealing with this version skew issue. Have you looked into those and decided they are insufficient?

From what I know that only applies if you use Vercel to host the site? Or am I missing something?

When SvelteKit fetches an asset, it will check if the deployed version number has changed. If the version has changed, it performs a full-page reload.

[andersekdahl]

When SvelteKit fetches an asset, it will check if the deployed version number has changed. If the version has changed, it performs a full-page reload.

That's great to hear, but what I encountered was that during our deploy the start page was served from version 1 and then when my browser wanted to request the needed assets those were gone because the instance that got the requests had version 2 and I got a lovely old-school page of unstyled HTML and no scripts.

[teemingc]

Can you confirm if this is the same issue as #9089 ? Otherwise, we need a minimal reproduction to further diagnose this as a separate issue.

[andersekdahl]

It's hard to say, feels like there's a lot of people with slightly different cases in that thread, but it's certainly very similar.

Otherwise, we need a minimal reproduction to further diagnose this as a separate issue.

You can either delete random files in _app/immutable before starting the server or block requests to them in devtools. If I block requests to the CSS files there' no error handling of that CSS failing to load. And I wouldn't expect Sveltekit to be able to handle it either, since the file is from a previous deploy and that file does not exist in the new deploy.

The only thing I can think of to repair it is to fallback on an external storage of old build artifacts, and to implement that I'd need to be able to hook into the 404 handling.

[teemingc]

Otherwise, we need a minimal reproduction to further diagnose this as a separate issue.

You can either delete random files in _app/immutable before starting the server or block requests to them in devtools. If I block requests to the CSS files there' no error handling of that CSS failing to load. And I wouldn't expect Sveltekit to be able to handle it either, since the file is from a previous deploy and that file does not exist in the new deploy.

Can you provide a repository and list the expected and actual outcomes?

[Conduitry]

What this is asking for specifically, I guess, is an option to disable the change in #9802/#11597, but that doesn't feel like the right way to address whatever the underlying issue is here.

[andersekdahl]

but that doesn't feel like the right way to address whatever the underlying issue is here.

Maybe, but the only way SvelteKit could handle this situation would be to add onerror handlers on all CSS and scripts and if any of them fail with a 404, reload the page. And then also have some logic to avoid ending up in infinite reload if the asset is actually missing and not just missing because of deploy timing.

I don't expect SvelteKit to solve this for me and it's a bit of an edge case, but does happen in real-life if you have enough traffic during deploy time. Which is why I was asking for the hook so I could solve it in userland.

[teemingc]

This sounds like something a service worker would be useful for doing (if I'm not mistaken). https://kit.svelte.dev/docs/service-workers#inside-the-service-worker . Instead of caching the assets, could it be possible to trigger a full page reload when an asset fails to be fetched?

[andersekdahl]

A service worker can't itself trigger a reload, it can only send a signal to the main thread to perform the reload. But it would certainly be a cleaner solution to detect 404s than onerror on CSS/scripts.

But either way this can't be dependent on a service worker since it might not be installed yet for the request that this happens to.