coverage: 81.017% (+0.02%) from 80.997%
when pulling 60e2a3d on 7ttp:fix/auth-non-blocking-subscriber-notifications
into 09aa106 on supabase:master.

@7ttp Thanks for the PR
@mandarini @grdsdev Would be great if you can review this.

This PR will re-introduce the SSR OAuth bug that #2039 fixes.

The SSR callback is async:

  client.auth.onAuthStateChange(async (event) => {                                       
    await applyServerStorage({...})                                                      
  })                                                                                     

With this PRs non-blocking approach, applyServerStorage won't complete before serverless functions return, causing the same cookie-setting failure as the original setTimeout issue.

We need a different solution that:

1. Prevents deadlocks when callbacks call getUser() or getSession()
2. Ensures critical async operations (like cookie-setting) complete before returning
3. Works in both serverless and long-running server contexts

Potential approaches:

• Detect if callback is async and warn/error if it awaits other auth methods
• Document that callbacks MUST NOT await auth methods
• Refactor locking mechanism to allow reentrant calls during notifications
• Make cookie-setting synchronous (queue writes instead of awaiting)

hey @mandarini almost forgot about this,
was curious if this aswell is being discussed internally (in the recent lock related discussion) ?
or should i continue with the suggested approaches? 😅💚

let's park it for now @7ttp ! I want to see how the internal discussion goes!! Thank you for ALL the help!!!!! 💚