CredentialsManager exception not being catched

[podybman]

Checklist

• The issue can be reproduced in the Auth0.Android sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Hi folks,

I'm having a case where an Exception is raised from the CredentialManager but it's not catched:

 Fatal Exception: com.auth0.android.authentication.storage.CredentialsManagerException: A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Please try saving the credentials again.
       at com.auth0.android.authentication.storage.SecureCredentialsManager.saveCredentials(SecureCredentialsManager.kt:196)
       at com.tt.authentication.AuthenticationFrameworkModule$providesAuthenticationFramework$3.invokeSuspend(AuthenticationFrameworkModule.kt:160)
       at com.tt.authentication.AuthenticationFrameworkModule$providesAuthenticationFramework$3.invoke(AuthenticationFrameworkModule.kt:8)
       at com.tt.authentication.AuthenticationFrameworkModule$providesAuthenticationFramework$3.invoke(AuthenticationFrameworkModule.kt:4)
       at com.tt.authentication.AuthenticationFramework.saveCredentials(AuthenticationFramework.kt:142)
       at com.tt.authentication.AuthenticationFramework.access$saveCredentials(AuthenticationFramework.kt)
       at com.tt.authentication.AuthenticationFramework$startSession$2$1$1$1$1.invokeSuspend(AuthenticationFramework.kt:57)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:111)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:99)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:802)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:706)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt)

This is identical to #258, #330 and #540

While the root cause probably is an issue about something not being thread-safe, the biggest issue for me is that the SDK doesn't catch its own exception. I don't think it's acceptable for a third-party to crash an app, especially on an error that is not user facing and doesn't result in any problem (here the user stay identified, no issue).

Reproduction

Unclear how to reproduce easily

Additional context

No response

Auth0.Android version

2.10.2

Android version(s)

13

[pmathew92]

@podybman Apologies for the late reply. I believe you might have hit the issue while trying to save the credentials using the saveCredentials method. In this scenario it is the applications responsibility to catch the exception and handle it accordingly

[podybman]

We fixed it by catching it and the catch does nothing. User is not logged out or anything as a result. This error has zero effect which to me is a very good sign that this is not the place for a third party SDK to throw an exception rather than just a log.
I would understand if it were a non recoverable situation obviously, but this is not the case. What happens is that the SDK attempts to write the same thing on two separate threads and one of them fails resulting into absolutely no consequence to the user.

[pmathew92]

The exception is thrown to let the user know the save operation has failed . The user credentials might not be fully saved when the exception is thrown so its better for the application to retry saving the credentials .
Are the credentials getting saved completely when the exception is thrown in your scenario ?