[irisfield]

What kind of change does this PR introduce?

Bug fix. Closes #1823.

What is the current behavior?

sign_out() suppresses every AuthApiError and nothing else, so whether a failed logout request clears the local session depends on how the error was classified, not on the scope. With global, a 429 or a JSON 500 clears the session and returns without an error even though the server revoked nothing, while a 503 raises and keeps it. With local, a 503 keeps the session.

What is the new behavior?

I moved the admin.sign_out() call into its own try. A 401, 403, 404 or AuthSessionMissingError counts as already signed out (_is_signed_out_error), and any other error is handled by scope, following supabase/supabase-js#2786:

• global raises and keeps the session, so the call can be retried or replaced with a local sign out.
• local removes the session and emits SIGNED_OUT before sending the request, then raises if the request fails. If the access token has expired and the refresh fails with an AuthRetryableError, it still removes the session before raising. A SIGNED_OUT subscriber that raises does not stop the request, and its error is raised after the request is sent.
• others raises and keeps the session.

The sign_out() docstring now describes each scope.

Additional context

• global callers that get a 429 or a JSON 500 now see an exception where they used to get a silent success.

[irisfield]

@grdsdev When you get a chance, could you take a look at this one? It brings sign_out() in line with supabase/supabase-js#2786, which merged yesterday.