Race condition in auth flow in SPA mode

[xollaborator]

Version

@nuxtjs/supabase: 1.5.1
nuxt: 3.17.3

Reproduction Link

My repo is private but how that in general should work with supabase and user credentials, allowed domains, etc? Maybe some more guidance or better starting point might make this easier, e.g. will Stackblitz repo without credentials make sense? I can prepare that if will be needed.

nuxt.config.ts

{
  ssr: false,
  supabase: {
    redirectOptions: {
      callback: '/welcome',
      exclude: ['/login', '/welcome'],
      login: '/login',
      saveRedirectToCookie: true, // or false
    },
    useSsrCookies: false, // or true
  },
},

plugins/supabase.client.ts

import { defineNuxtPlugin, useSupabaseClient } from '#imports'
import { setSupabaseClient } from '@services/supabase/index.js'

export default defineNuxtPlugin(async () => {
  const client = useSupabaseClient()

  console.log(
    '[Supabase]',
    // await client.auth.getSession(), // uncommenting this line solves the issue for the failing case mentioned below
  )

  setSupabaseClient(client)
})

Steps to reproduce

1. Nuxt in SPA mode (ssr: false, useSsrCookies can be true or false - BTW. maybe it could use ssr flag from nuxt config as a default, instead of being true, while ssr is false)
2. Supabase user is logged in.
3. Cache is disabled in DevTools/Network.
4. Specific url is opened, e.g. /clients.

What is Expected?

Requested page /clients is opened directly. It was working like that before the update from 1.5.0.

What is actually happening?

1. User is redirected to login, then to welcome (callback page) and then to dashboard since the account is properly set. User is not redirected to original page.

What have I investigated?

I assume this might be infrequent issue that was uncovered with removal of getSession: https://github.com/nuxt-modules/supabase/pull/490/files#diff-9cd9641dbb78788b0360d0066e5fc02a0913aa62ab1fc0539bfe51d2d1f1ac3aL47
That call was happening early enough so when middlaware was checking if user is authenticated the state was already populated.
With enabled cache or slow 3G the issue is not occuring. But without await before getSession in plugin it is still there.

[b1sh0pe]

I'm facing a similar issue where in one of my auth-related plugins useSupabaseUser composable doesn't return the user record after the change that is mentioned in the "What have I investigated?" section. Manually fetching the user using supabase.auth.getUser returns a record, so cookies are present.

If I compare 2 flows, with v1.5.0:
Magic link -> /confirm page -> protected route

And with v1.5.1:
Magic link -> /confirm page -> sign-in page -> protected route (manual redirect from sign-in page)

Not sure what's the best way to smooth it out, but just wanted to share it's also affecting my case.