Open deronek opened 1 month ago
I have this issue:
Error: Cannot use
cookies.set(...)
after the response has been generated
even without streaming.
Yes, we have a race condition here, and it works even without streaming and simple +layout.server.js.
Problem here event.local.auth()
actual try to set cookie for wrong event
, because this function bind to event inside hook
.
Context is here https://github.com/sveltejs/kit/issues/11813
Basically we should have a way to manually provide event object to the auth function.
Environment
Also reproducible on Vercel deployment
Reproduction URL
https://github.com/deronek/sveltekit-auth-example/
Describe the issue
@auth/sveltekit@0.8.0
broke an undocumented behavior which I was using in my application, which was lazily retrieving theSession
object in a root layout, then awaiting it where necessary in the application. This way, I could start rendering full page, while displaying spinners/skeletons on data which need user data from theSession
object.9694 introduces setting cookies when retrieving the
Session
object. Migrating to version@auth/sveltekit@0.8.0
(replacinggetSession
withauth
) will cause a possible race condition, where if the first response was already sent from the server before below code is executed:https://github.com/nextauthjs/next-auth/blob/6116736ae2103ea7357b08e88c608af1f17fe70b/packages/frameworks-sveltekit/src/lib/actions.ts#L120-L125
we will receive an error:
traced to here: https://github.com/sveltejs/kit/blob/f80ba75dfd967fb9d28d705d6891933bab603dc9/packages/kit/src/runtime/server/respond.js#L541-L543
How to reproduce
Loading...
beforeSign in
button appears.Could not load user data
and below error on server side.Live deployment on Vercel: sveltekit-auth-example-eight-smoky.vercel.app
Expected behavior
Session
should be allowed to be streamed using Promise.While I find the feature of streaming the
Session
object to be potentially beneficial, I acknowledge that there may be valid reasons why it's not implemented as such. This opens the floor for discussion, and I'm welcome to insights on this matter. I see following outcomes of this discussion:Session
promise should NEVER be streamed, and we should indicate that explicitly in the documentation,Session
promise should allow to be streamed, and it would be fairly easy to refactor theauth
function to allow for this,Session
promise should theoretically allow to be streamed, but it would a significant refactor of library's core functionality and the handler hooks.