workerd
workerd copied to clipboard
🐛 BUG: The cache field on RequestInitializerDict is not implemented in fetch
Which Cloudflare product(s) does this pertain to?
Workers for Platforms
What version of Wrangler are you using?
Latest
What operating system are you using?
All
Describe the Bug
Making a fetch request with the cache field throws the following exception.
The cache field on RequestInitializerDict is not implemented
const response = await fetch(url, {
cache: 'no-store',
method: 'POST',
body: JSON.stringify(body),
headers: {'Content-Type': 'application/json'}
})
This was reported in our database driver in https://github.com/planetscale/database-js/pull/102. We're using the cache attribute to advise the runtime to avoid caching any responses since the response body is an SQL result set that varies on every request.
A similar issue was reported in https://github.com/cloudflare/workers-sdk/issues/192, but I'm not sure what the resolution was there.
Is support for the standard Request.cache attribute planned? Ideally, we'd like to treat all JS runtimes identically and rely on the fetch interfaces to hide implementation details from the driver. Even "supporting" the attribute without throwing, but with no actual implementation, would be helpful here.
@dgraham Downgrading to 1.6.0 seems to be a solution for now.
Will be watching this space and https://github.com/planetscale/database-js/pull/102 for a solution which will work with latest version too, FYI.
Thanks.
Same issue
@dgraham — we're going to address this, just a matter of timing. Should know more specifics soon.
Still seeing this:
✘ [ERROR] Error: The 'cache' field on 'RequestInitializerDict' is not implemented.
Any workaround till this attr is implemented?
@ignoramous if ur using planetscale https://github.com/planetscale/database-js/pull/102#issuecomment-1508219636
I have same error with upstash redis db The 'cache' field on 'RequestInitializerDict' is not implemented. I deployed Next.js app with pages.
import { Redis } from "@upstash/redis"
const redis = new Redis({
url: process.env.UPSTASH_REDIS_REST_URL!,
token: process.env.UPSTASH_REDIS_REST_TOKEN!,
})
try {
data = await redis.get(userEmail);
} catch (err) {
return new Response(`Could not access DB ${err}`, { status: 500 })
}
I have same error with upstash redis db
The 'cache' field on 'RequestInitializerDict' is not implemented.I deployed Next.js app with pages.import { Redis } from "@upstash/redis" const redis = new Redis({ url: process.env.UPSTASH_REDIS_REST_URL!, token: process.env.UPSTASH_REDIS_REST_TOKEN!, }) try { data = await redis.get(userEmail); } catch (err) { return new Response(`Could not access DB ${err}`, { status: 500 }) }
@satpalsr upstash redis should have fixed this issue @v1.20.3.
https://github.com/upstash/upstash-redis/issues/338#issuecomment-1508551843
I was using @upstash/redis, it's working with @upstash/redis/cloudflare. Thanks
Any update on this? I am still seeing
The 'cache' field on 'RequestInitializerDict' is not implementederror when using latest @planetscale/database. Any workaround suggestions are appreciated. Thanks!
@trd-sys There is a workaround in https://github.com/planetscale/database-js/pull/102#issuecomment-1508219636
Hope this bugs will solved in features soon 😆
@dgraham — we're going to address this, just a matter of timing. Should know more specifics soon.
Any update?
Adding the below to my config fixed the issue for my worker: const config = { host: 'aws.connect.psdb.cloud', username: 'test', password: 'password', fetch: (url: any, init: any) => { delete init['cache'] return fetch(url, init) } };
The delete cache part of the config seems to fix.
The delete init["cache"] workaround is not working in my case
I got the same issue on production w/ lucia
It's been almost a year, do we have a timeline to when this might be fixed?
Experiencing the same issue in NextJs 14 app
... do we have a timeline to when this might be fixed?
No specific timeline yet but I'll raise this again in internal discussions to see if we can get something scheduled.
Experiencing same issue using wrangler (3.39.0) as my main api 🫤.
If anyone got this issue in combination with supabase-js. In the following issue I added a comment describing a temporary workaround: https://github.com/supabase/supabase-js/issues/1001#issuecomment-2027790018.
Getting this when trying to use @supabase/ssr on an Astro site deployed to Pages
Getting this when trying to use
@supabase/ssron an Astro site deployed to Pages
You can try downgrading like described from this user on another issue on supabase-js (https://github.com/supabase/supabase-js/issues/1001#issuecomment-2027560043). This is obviously just a temporary fix for now.
Thanks! I actually found a kinda dumb but-it-works workaround.
import { createServerClient, type CookieOptions } from "@supabase/ssr"
import type { AstroCookies } from "astro"
export const supabase = (env: Env, cookies: AstroCookies) => createServerClient(
env.SUPABASE_URL,
env.SUPABASE_ANON_KEY,
{
auth: {
flowType: 'pkce'
},
global: {
fetch: (...args) => {
//// TEMP
// https://github.com/cloudflare/workerd/issues/698
if (args[1]?.cache) {
delete args[1].cache
if (!args[1]?.headers)
args[1].headers = {}
// @ts-ignore
args[1].headers['Cache-Control'] = 'no-store'
}
////
return fetch(...args)
},
},
cookies: {
get(name: string) {
return cookies.get(name)?.value
},
set(name: string, value: string, options: CookieOptions) {
cookies.set(name, value, options)
},
remove(name: string, options: CookieOptions) {
cookies.delete(name, options)
},
},
}
)
I'm encountering the same problem when running auth.setSession from a Cloudflare worker. It just started a few days ago. What is really weird and drives me crazy is that even when I reverted back all the packages I still get the same error. I tried to delete npm cache, install all packages again. Nothing works. Running with: Supabase 2.39.7 Wrangler 3.32 Compatability date: 2023-12-18
@nechmads
Have you tried the method described here? https://github.com/supabase/supabase-js/issues/1001#issuecomment-2027790018
Had the same issue with not being able to downgrade.
@davbauer OK. I've been going crazy for the past day trying to figure this out. For me, it's not enough to add: "@supabase/auth-js": "^2.62.0" When doing this it sometimes worked and sometimes not. I had a totally new project where it was working and another when it didn't. It something about how npm is installing packages. What solved it for me for good was to also add:
"overrides": {
"@supabase/auth-js": "^2.62.0"
}
in order to make sure that the right version is always used.
👋 I've put together a snippet to workaround this for now that replaces fetch with a custom one that will remove the cache property if it's not supported.
Tested locally with wrangler. It should fallback to the proper implementation when support becomes available in the future. Just make this one of the first bits of code to run
https://gist.github.com/tjenkinson/53b5724bf8112487f6bd797368e02b56
why cant workerd just ignore the cache field? it would make things a LOT easier.
Looking at supporting cache: 'default' and cache: 'no-store' as options here as shortest path. Know this is painful right now and working towards something we can do ASAP.
Unfortunately not quite safe to ignore the field — you might set something like cache: 'no-store', and then if the request was cached, could lead to confusing behavior, bugs and other types of more subtle and harder to debug issues with packages you might depend on.
Changing the label on this to feature-request from bug. Will be upping the priority on getting this implemented.
@nechmads
Here's a pnpm patch that can be used for @supabase/auth-js in the meantime:
diff --git a/dist/main/lib/fetch.js b/dist/main/lib/fetch.js
index f6394f712fe187a19c833060524ac7f2949ef64a..a510e18a743ccc4edef0e2011ce8574fff2377b5 100644
--- a/dist/main/lib/fetch.js
+++ b/dist/main/lib/fetch.js
@@ -100,7 +100,10 @@ async function _handleRequest(fetcher, method, url, options, parameters, body) {
result = await fetcher(url, Object.assign(Object.assign({}, requestParams), {
// UNDER NO CIRCUMSTANCE SHOULD THIS OPTION BE REMOVED, YOU MAY BE OPENING UP A SECURITY HOLE IN NEXT.JS APPS
// https://nextjs.org/docs/app/building-your-application/caching#opting-out-1
- cache: 'no-store' }));
+ //
+ // TODO: removed due to https://github.com/cloudflare/workerd/issues/698
+ // cache: 'no-store'
+ }));
}
catch (e) {
console.error(e);
diff --git a/dist/module/lib/fetch.js b/dist/module/lib/fetch.js
index ffb8e951b78a3f6648668e401851550862490e2c..79b934ce28c3deebb2febb19ddacbd7be2196695 100644
--- a/dist/module/lib/fetch.js
+++ b/dist/module/lib/fetch.js
@@ -95,7 +95,10 @@ async function _handleRequest(fetcher, method, url, options, parameters, body) {
result = await fetcher(url, Object.assign(Object.assign({}, requestParams), {
// UNDER NO CIRCUMSTANCE SHOULD THIS OPTION BE REMOVED, YOU MAY BE OPENING UP A SECURITY HOLE IN NEXT.JS APPS
// https://nextjs.org/docs/app/building-your-application/caching#opting-out-1
- cache: 'no-store' }));
+ //
+ // TODO: removed due to https://github.com/cloudflare/workerd/issues/698
+ // cache: 'no-store'
+ }));
}
catch (e) {
console.error(e);
diff --git a/src/lib/fetch.ts b/src/lib/fetch.ts
index 010f751aaccd30976a93951b71f60a5c282c0e65..36c6ff45b9b1ac665de7fa4ed36d6f8900a6d67b 100644
--- a/src/lib/fetch.ts
+++ b/src/lib/fetch.ts
@@ -179,7 +179,9 @@ async function _handleRequest(
...requestParams,
// UNDER NO CIRCUMSTANCE SHOULD THIS OPTION BE REMOVED, YOU MAY BE OPENING UP A SECURITY HOLE IN NEXT.JS APPS
// https://nextjs.org/docs/app/building-your-application/caching#opting-out-1
- cache: 'no-store',
+ //
+ // TODO: removed due to https://github.com/cloudflare/workerd/issues/698
+ // cache: 'no-store',
})
} catch (e) {
console.error(e)