[mobile] Auth currentSession is null and client cannot recover from this state / user gets kicked off.

[iosephmagno]

Bug report

This is a well-known issue that might be affecting only mobile. Several improvements have been made during past year, but issue is still there and it is P0 for us, as reported here:
#860 (comment)

• [X ] I confirm this is a bug with Supabase, not with my own application.
• [X ] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

We use flutter plugin.

Mobile app at some point gets into a state where currentSession is always null and client cannot recover from this state, not even with subsequent app launches. Currently, when this happens, app becomes unusable, stuck in the splash screen, unless we kick off user and ask him to signin back via otp code (which is not an option).

We have been mentioning this issue for a long time, and you guys have been so kind to work on it trying to help. But issue is still there and this makes Supabase Auth not being production-ready for mobile apps. Situation is even worst when app is a chat/ messenger, coz if we kick off users, they will also be scared to loose their chats.

We suggested a potential solution, named recoveryToken, which was based on the idea of Auth server giving to the client an extra token (at registration) that client could save to encrypted sharedprefs (or flutter secure storage) and use later on to recover from this state (sort of sending to Auth server the recoveryToken when currentSession is null after 3 retries and getting authenticated this way). See here #860 (comment)
Note: For security reason, client could send to Auth server the recoveryToken + last 3 used tokens. This would make the procedure even more secure. But anyway, whatever solution would be fine, meantime we would appreciate if you guys could provide a workaround for us.

CC: @kiwicopple @dshukertjr

To Reproduce

There is no flow to reproduce this issue apart from launching and closing app multiple times in whatever context (online, offline, poor/unstable network, etc) and just get hit by this issue out of the blue (mostly 1-2 times every a few months).

Expected behavior

Mobile app that uses Supabase to authenticate users, should "always" receive a valid currentSession. App should never get stuck and user should never be kicked off / asked to sign in back with OTP code. This is not acceptable in a mobile context and users also freak out coz they think they lost their data.

System information

├── supabase_flutter 2.5.6
│ ├── supabase 2.2.2
│ │ ├── functions_client 2.2.0
│ │ ├── gotrue 2.8.1
│ │ ├── postgrest 2.1.2
│ │ ├── realtime_client 2.1.0
│ │ ├── storage_client 2.0.2

[iosephmagno]

@dshukertjr it occurred again. Cc: @kangmingtay

E/flutter (19191): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: AuthException(message: AuthRetryableFetchError, statusCode: null)
E/flutter (19191): 
I/flutter (19191): AuthException(message: AuthRetryableFetchError, statusCode: null)
I/flutter (19191): #0      GoTrueClient.notifyException (package:gotrue/src/gotrue_client.dart:1190:32)
I/flutter (19191): supabase/auth#1      GoTrueClient.recoverSession (package:gotrue/src/gotrue_client.dart:979:7)
I/flutter (19191): <asynchronous suspension>
I/flutter (19191): supabase/auth#2      SupabaseAuth.recoverSession (package:supabase_flutter/src/supabase_auth.dart:90:11)
I/flutter (19191): <asynchronous suspension>
I/flutter (19191): supabase/auth#3      CancelableCompleter.complete.<anonymous closure> (package:async/src/cancelable_operation.dart:425:16)
I/flutter (19191): <asynchronous suspension>

@kiwicopple can you please check if this suggestion might be a fix or might be used as a temporary workaround ? As mentioned to Tyler, the issue is way more severe than what might seem at first thought. It will harm the brand reputation and cause app uninstalls.
#860 (comment)

Also, if a workaround cannot be implemented soon, is there a way for us to not use Supabase Auth? We currently use Auth and Database, but as long as Auth is not production ready we might be willing to use an alternative, if any.
Thx.

[iosephmagno]

Hello guys, we would appreciate if you could make time to either come up with a fix or suggest us a workaround.

As long as a fix is not available we cannot open Presence to the public.
https://apps.apple.com/app/presence-messenger/id6504456930

@kiwicopple a successful Presence would be a nice news for Supabase as well: I discussed this with Tim Palmer, if you wanted to know more, I'd be happy to talk. Best!

[iosephmagno]

@dshukertjr it occurred again. Cc: @kangmingtay

E/flutter (19191): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: AuthException(message: AuthRetryableFetchError, statusCode: null)
E/flutter (19191): 
I/flutter (19191): AuthException(message: AuthRetryableFetchError, statusCode: null)
I/flutter (19191): #0      GoTrueClient.notifyException (package:gotrue/src/gotrue_client.dart:1190:32)
I/flutter (19191): supabase/auth#1      GoTrueClient.recoverSession (package:gotrue/src/gotrue_client.dart:979:7)
I/flutter (19191): <asynchronous suspension>
I/flutter (19191): supabase/auth#2      SupabaseAuth.recoverSession (package:supabase_flutter/src/supabase_auth.dart:90:11)
I/flutter (19191): <asynchronous suspension>
I/flutter (19191): supabase/auth#3      CancelableCompleter.complete.<anonymous closure> (package:async/src/cancelable_operation.dart:425:16)
I/flutter (19191): <asynchronous suspension>

@kiwicopple can you please check if this suggestion might be a fix or might be used as a temporary workaround ? As mentioned to Tyler, the issue is way more severe than what might seem at first thought. It will harm the brand reputation and cause app uninstalls. supabase/supabase-flutter#860 (comment)

Also, if a workaround cannot be implemented soon, is there a way for us to not use Supabase Auth? We currently use Auth and Database, but as long as Auth is not production ready we might be willing to use an alternative, if any. Thx.

@dshukertjr We also have been hit by this other one #171

[iosephmagno]

@dshukertjr hello, pasting this also here coz seems related. Wrote also to support. As mentioned, with users being kicked off, we cannot ship our product. Please LMK if/how we can help further with this. It would be also helpful if a workaround could be provided until a final fix is made, we suggested one but anything that lets client recover from login exceptions would be appreciated.
#930

[iosephmagno]

Also noticed this one. #928

So there are these auth issues which are currently breaking mobile clients in production.
@dshukertjr @kangmingtay @hf @kiwicopple
My thought is: after many months of working on this and given the intrinsic complexity of debugging/fixing the issues on a mobile platform, we cannot trust a fix and ship product.

It would be best if you guys could setup an extra measure that would always allow client to recover session when shit happens (ie. network issues, local caching issues). It can be a recoverToken or a set of 2-3 past used tokens inserted to the auth table and also cached on client. Server-wise that would be easy to code, and if client fails to connect, it would call methods by also passing recoveryToken as extra parameter.
Wdyt?
Can we please also mark this as P0?

[iosephmagno]

@dshukertjr @Vinzent03 maybe saw something here https://github.com/supabase/supabase-flutter/blob/ec5d47e195626a66ecbe0da917d781155011f27d/packages/supabase_flutter/lib/src/local_storage.dart#L75-%23L80

IIRC this might fail if app is in background.
To avoid issues we had to invoke SharedPreferencesFoundation.registerWith()

See attached file from Presence codebase

[iosephmagno]

Also noticed this one. supabase/supabase-flutter#928

So there are these auth issues which are currently breaking mobile clients in production. @dshukertjr @kangmingtay @hf @kiwicopple My thought is: after many months of working on this and given the intrinsic complexity of debugging/fixing the issues on a mobile platform, we cannot trust a fix and ship product.

It would be best if you guys could setup an extra measure that would always allow client to recover session when shit happens (ie. network issues, local caching issues). It can be a recoverToken or a set of 2-3 past used tokens inserted to the auth table and also cached on client. Server-wise that would be easy to code, and if client fails to connect, it would call methods by also passing recoveryToken as extra parameter. Wdyt? Can we please also mark this as P0?

But as mentioned here, so many things can go wrong on mobile platforms and we cannot risk to kick off a logged user on these failures.

[iosephmagno]

@dshukertjr @Vinzent03 maybe saw something here https://github.com/supabase/supabase-flutter/blob/ec5d47e195626a66ecbe0da917d781155011f27d/packages/supabase_flutter/lib/src/local_storage.dart#L75-%23L80

IIRC this might fail if app is in background. To avoid issues we had to invoke SharedPreferencesFoundation.registerWith()

See attached file from Presence codebase

@dshukertjr hello, did you have the chance to test this? We also access SharedPreferences in background mode (during cloud backups) and we were hit by issues when we didn't register the plugin before accessing its instance (on both platforms, but especially on iOS).