Error: Cannot use cookies.set(...) after the response has been generated about cmsaasstarter HOT 8 OPEN

I can try to take that task up as I'll be working on some similiar stuff anyways

from cmsaasstarter.

I've seen this too, seems to be inside Supabase API. I think it's only on dev mode (at least I've never seen it on prod, confirmation would be good).

We have a PR updating that dependency (coupled to some SSR work). If we don't take that, we should at least bump the dep for this issue.

from cmsaasstarter.

am facing this issue too - is there any fix coming soon ?

from cmsaasstarter.

I updated deps yesterday. Can you try pull that and see if this is fixed? I couldn't repo this after the update.

from cmsaasstarter.

I have just started using the template today, and I'm facing this issue too.
So I can confirm, it's not fixed.

from cmsaasstarter.

The reason why this happens is usually somewhat architecturally related. The auth-helpers package isn't recommended anymore and should be removed from this project. That's a first good step.

Reason why this can happen (and why it only happens occasionally): When the session gets refreshed (which is when it expires) and this is done in a context of Svelte were setting cookies is not allowed, then this error will pop up. Then, after refreshing the page, the session will usually be proper resolved in the first point and not appear for some more time until it expires etc.

Here's the most recent docs about supabase/ssr package: https://supabase.com/docs/guides/auth/server-side/creating-a-client?environment=middleware&queryGroups=framework&framework=sveltekit

from cmsaasstarter.

Thanks @activenode !

Note: we also have a PR to move to SSR (but it's held up on another bug in supabase): #63

Sounds related, so let's not double up work unless there's a clean fix for main separate from that.

from cmsaasstarter.

Hey, I had exactly the same issue and found a workaround for this - in hooks.server.ts I have added the following:

...
  const response = await resolve(event, {
    filterSerializedResponseHeaders(name) {
      return name === "content-range"
    },
  })

  return response

Once I was waiting to finish al session related it worked - seemes for me like the issue happens during the session check -> it happens prior to all relevant session related actions (supabase etc.)

from cmsaasstarter.