-
Notifications
You must be signed in to change notification settings - Fork 42
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
2.1.1 throws unhandled exception - Crash #237
Comments
Thanks for the report. @NikitaAvraimov-okta could you take a look? |
Internal ref 439256 |
Any updates on this ? (Just wondering if you figured something out ?) Also wondering if we can get the temp fix of having a null check for now on queuedPromise so that it at least doesn't crash. |
@Qwin sorry for the delay. Before the fix is released you can try editing your local OktaSdkBridgeModule.java replicating changes in related PR |
@NikitaAvraimov-okta thank you, will try it out. |
Fixed #239 , please reach out if there are other questions! |
I'm submitting a:
Current behavior
When using react-native-share library (7.2.0) and opening a share tab and then tapping on any of the services (gmail) and then going back to the app, Okta throws the following exception causing the app to crash, I debugged the code and it seems like onCancel is being invoked and queuedPromise is null.
Expected behavior
Does not fire SignIn event on threadpool abrupt kill of task, does not crash on queuedPromise.
Minimal reproduction of the problem with instructions
Extra information about the use case/user story you are trying to implement
After looking further I see that the ThreadExecutor somehow cancels the futureTask (somehow in conflict with the pools with the share library maybe) in webAuthClient. Causing the registerCallback in WebAuthClientImpl to be invoked with type SIGN_IN and result CANCELLED. Again nobody invoked SignIn so the queuedPromise is null thus a crash happens.
I added a simple if statement for queuedPromise as a test on the canceled method, which solved the crashing of course, and the app functions normally and the token is still valid as well. But I am puzzled as to what is happening here. Of course it would be great if you guys added a null check just for safety but honestly it should never fire.... its just a workaround afterall.
SyncWebAuthClient
This does not happen in version 1.12.1 of okta-react-native.
Environment
node -v
): v14.18.0The text was updated successfully, but these errors were encountered: