Cloudflare Adapter: Parameter to disable workers cache

[DevOfManyThings]

Describe the problem

Currently there's no way to avoid caching a result in the workers cache if a response is cacheable.

Not everything which is cachable should be stored in the workers cache, primarily because there's no way to invalidate it globally, running cache.delete only removes it from the datacentre the command is ran in, depending on the application this can then lead to inconsistent state globally. Compared to eg the cloudflare cdn where you can invalidate it globally using the api.

Describe the proposed solution

Add some sort of parameter that is used to determine whether the response should be added to the workers cache or not, currently in the cloudflare-adapter it checks a couple of headers, if possible adding something to the sveltekit config to enable/disable workers cache would be great, else maybe a header which if included skips workers cache?

Alternatives considered

Current workaround is using a custom implementation of the cloudflare-adapter, which is a copy of the current master version just with the workers cache commented out. It'd be nicer to stay in sync with the master project without having to maintain that.

Importance

would make my life easier

Additional Information

No response

[Rich-Harris]

IIUC the only objects that are cached are static assets, which can't change for the duration of the deployment. Or are you saying that the cache survives between deployments?

[DevOfManyThings]

IIUC the only objects that are cached are static assets, which can't change for the duration of the deployment. Or are you saying that the cache survives between deployments?

I deleted my comment to reply to this properly and didn't copy my original response, apologies if this spams you.

There's 3 types of cache available with cloudflare:

1. Static assets that are uploaded during build time. This uses either the CDN or some magic with cloudflare KV
2. Dynamic responses stored in the workers cache, as can be seen in this PR
3. Dynamic responses stored in the cloudflare global CDN. Normally it doesn't store html/json, but you can setup page rules to cache them if you want.

1 is very useful for serving the compiled javascript files. 2 and 3 vary depending on your use case, however presently if you try to use cache 3 by returning cache control headers, it also gets stored in cache 2, with the issues I mentioned in the OP around the workers cache being difficult to invalidate.

It wouldn't be hard to update the cloudflare-adapter to check for a header, eg disable-workers-cache, and skip the workers cache if that's present, config is probably nicer but a little overkill. I could raise a PR for the header based approach but figured best to discuss this first.

[PH4NTOMiki]

Actually @DevOfManyThings the 2. and 3. are shared, and there is one more option, Workers KV

[DevOfManyThings]

@PH4NTOMiki Behind the scenes I think they're the same thing, but you interact with them in different ways so it's easier to consider them different solutions. You could use KV as a cache if you wanted but it's not quite the same thing (also it's paid whilst the CDN/workers cache are free).