-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Amplify.Auth.fetchAuthSession never ends #2816
Comments
Hi @Andrew0000, Can you show how you are calling Is there a reason that you are mixing RxJava and Coroutines? While I don't see any reason that it couldn't work, why not just use Can you
|
Hi @tylerjroach ,
In general it's called in a blocking way for a compatibility with different consumers. Please tell me if this is something that is not obviously prohibited. I tried with May be I will be able to provide more snippets later. Meanwhile, your answers will be helpful. |
Hi @Andrew0000
The mixing and matching of RxJava and Coroutines should not cause any compatibility issues, although it isn't an ideal implementation. Can you post a longer code snippet that shows how Please check and make sure the logging plugin is added like this. You should see a large amount of logs from Amplify by doing so.
|
By the way, it was really the problem, I just tried it without blocking calls and seems like it helped. But it really requires a lot of time to refactor the codebase to make it work in my case. This is why I'm asking why a legitimate blocking operator may freeze the Amplify library (not UI). |
Networking on the main thread is never permitted and the Android OS explicitly blocks it: https://developer.android.com/reference/android/os/NetworkOnMainThreadException. This is not an Amplify limitation, this is not allowed by Android. This isn't actually what is happening though, as internally, Amplify launches its own IO context to make the network request. What is happening, however, is that your example is calling
I tested this which did run to completion, however, it locked the UI for nearly 2 seconds, which is definitely something you cannot allow to happen in production. You haven't posted enough code to how you are subscribing to the Rx Completable to get a full picture for what is not allowing the call to happen. I don't believe the call is even being made.
This isn't happening. If it were hanging from the main thread the UI would be locked. There is only 1 main thread in an application and if Amplify were locking it, you would not be getting any UI updates. I understand you intention to write code in a synchronous way for easier implementation. RxJava (through chaining) and Kotlin Coroutines (through contexts) both allow you to write code in a more synchronous manner. All of these technologies still require that any blocking code is done off of the main thread. If your end goal is to update the UI after doing work on an IO thread, you should use a pattern that allows your UI to subscribe to Observer updates (ex: LiveData, Flow, etc) |
@tylerjroach As I mentioned there is no UI freeze. The blocking invocation happens in the background thread. You told that an exception should be expected if it's on the main. I responded: where is the Exception then? I'm not sure why are you talking about all these things. Can we now return to the question "Why a blocking invocation can hang Amplify"? Thread doesn't matter as far as I see. |
Here's a simpler reproduction of the bug:
Output:
Amplify hangs. |
The same with runBlocking inside:
Output:
Amplify hangs. |
Thank you for sending a full code block example. With this, I'm able to see a full picture of how you are using RxAmplify and AmplifyKt. I've been able to track exactly what you are running into. With this full example, we can see that none of your blocking call requests are blocking the main thread. Internally, Amplify Auth uses Coroutines to ensure that Auth calls are not executed in parallel and are queued to be run 1 at a time.
When the onSuccess/onError response is provided, the result is returned from within the plugin's coroutine scope that only allows for a single execution at a time. The code in your example that uses This explains why To avoid the lockup, we would recommend not mixing Amplify Coroutines and Amplify RxJava together, or use the workaround with the delay as you suggested. We will internally take an action item to look into preventing the deadlocks that can be produced by mixing our Coroutine and RxJava methods together. An Amplify internal change to the below code should avoid the deadlock.
|
@tylerjroach Thanks a lot for the explanation. |
I'm going to go ahead and close this issue since you are no longer blocked. #2822 addresses the scenario that was causing the deadlock. The next version of Amplify should prevent this scenario from occurring. |
This issue is now closed. Comments on closed issues are hard for our team to see. |
Before opening, please confirm:
Language and Async Model
Kotlin, Kotlin - Coroutines, RxJava
Amplify Categories
Authentication
Gradle script dependencies
Environment information
Please include any relevant guides or documentation you're referencing
https://docs.amplify.aws/gen1/android/build-a-backend/auth/accessing-credentials/
Describe the bug
Amplify.Auth.fetchAuthSession never ends.
Configuration
Flow
As you can see from the comments, fetchAuthSession() never returns a result. It just hangs there forever.
An interesting observation:
If I add something like Rx
.delay(1, TimeUnit.MICROSECONDS, Schedulers.io())
beforeCompletable.fromAction({ refreshTokens(forceRefresh = true) })
then everything works.With this observation it seems like the problem related to multithreading / synchronization / maybe a deadlock.
Reproduction steps (if applicable)
No response
Code Snippet
No response
Log output
No response
amplifyconfiguration.json
No response
GraphQL Schema
No response
Additional information and screenshots
No response
The text was updated successfully, but these errors were encountered: