workerd: 🐛 BUG: The cache field on RequestInitializerDict is not implemented in fetch

@dgraham — we’re going to address this, just a matter of timing. Should know more specifics soon.

Quick update on this… it’s going to take a bit of time to do and we need to do a bit more evaluation, so I cannot give a time estimate or a firm confirmation just yet, but… our current plan here is to start allowing the cache option to be set but the only acceptable values will be undefined or no-store initially. Passing the other spec-defined values, including default will throw with a better error than what we have currently. undefined will map to Worker’s current behavior. As I said, there are still a number of details to work out so we cannot commit to a timeline just yet but I wanted to update so that y’all know we’re actively looking at this.

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.

Changing the label on this to feature-request from bug. Will be upping the priority on getting this implemented.

It’s been almost a year, do we have a timeline to when this might be fixed?

Thanks.

- // UNDER NO CIRCUMSTANCE SHOULD THIS OPTION BE REMOVED, YOU MAY BE OPENING UP A SECURITY HOLE IN NEXT.JS APPS

💀 I wonder what the author who put that comment in there makes of this bug…

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

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

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.

👋 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

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

Same issue

why cant workerd just ignore the cache field? it would make things a LOT easier.

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

@ignoramous if ur using planetscale https://github.com/planetscale/database-js/pull/102#issuecomment-1508219636

Still seeing this:

✘ [ERROR]   Error: The 'cache' field on 'RequestInitializerDict' is not implemented.

Any workaround till this attr is implemented?

Had the same issue with a remix project using @supabase/ssr ^0.3.0 on Cloudflare Pages

Sorted it using @tjenkinson’s method.

Created a app/utils/supabase-ssr.cf-fetch.ts:

const originalFetch = globalThis.fetch;

globalThis.fetch = async function (...args) {
  try {
    return await originalFetch.apply(this, args);
  } catch (e) {
    if (!args[1] || typeof args[1] !== "object") throw e;

    const unimplementedCacheError =
      e &&
      typeof e === "object" &&
      "message" in e &&
      e.message === "The 'cache' field on 'RequestInitializerDict' is not implemented.";
    if (!unimplementedCacheError) throw e;

    const newOpts = { ...args[1] };

    // biome-ignore lint/performance/noDelete: No other option
    delete newOpts.cache;

    return originalFetch.apply(this, [args[0], newOpts]);
  }
};

export default globalThis.fetch;

then import in app/root.tsx

import "~/utils/supabase-ssr.cf-fetch";

This way I can just leave the code forever, or remove the single include and file when fixed 🥳

Getting this when trying to use @supabase/ssr on an Astro site deployed to Pages

Experiencing the same issue in NextJs 14 app

@rtconner it would be helpful if you provided a repro of it happening. Are you using a framework like Next or similar?

@jdgamble555 I use my above patch with SvelteKit. I believe you should also be able to use a handleFetch hook to accomplish the same as the global fetch replacement above.

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)
      },
    },
  }
)

Getting this when trying to use @supabase/ssr on 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.