-
Notifications
You must be signed in to change notification settings - Fork 35
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
Handle Receiver Callback Exception in CommandDispatcher interactive command #2305
Conversation
Can you try reproducing the issue by just hard-code throwing an NPE from that place in the code? I think we need at least some manual validation of this change |
I tried this, the application does not crash with my fix. Unfortunately in my case it hangs forever, because the result future that would be completed in completeAuthorization is not getting a result sent to it, so i'm guessing some background thread is hanging forever so nothing actually happens in my application. On the plus side i don't think this scenario would happen in the user scenario because if the strategy is never initialized, then the future would not be either. But i added a check for both anyway. |
...on/src/main/java/com/microsoft/identity/common/internal/controllers/LocalMSALController.java
Outdated
Show resolved
Hide resolved
common4j/src/main/com/microsoft/identity/common/java/controllers/CommandDispatcher.java
Outdated
Show resolved
Hide resolved
…tion-library-common-for-android into fadi/receiver-exception
...on/src/main/java/com/microsoft/identity/common/internal/controllers/LocalMSALController.java
Outdated
Show resolved
Hide resolved
common4j/src/main/com/microsoft/identity/common/java/controllers/CommandDispatcher.java
Outdated
Show resolved
Hide resolved
common4j/src/main/com/microsoft/identity/common/java/controllers/CommandDispatcher.java
Outdated
Show resolved
Hide resolved
...on/src/main/java/com/microsoft/identity/common/internal/controllers/LocalMSALController.java
Outdated
Show resolved
Hide resolved
Revert changes made to method signature to return back a ResultFuture instead of a Future. It seems to have introduced a breaking change in MSAL, instead of debugging this during release time, I rolled back part of the solution for the original google crash. The fix still does the same thing, just by using a type casting rather than explicit return type being set to ResultFuture. As mentioned in the original PR, this scenario should theoretically be impossible anyway, as if we fail out of authorization because the strategy is null, then the future would not be initialized, but keeping the result future check there for additional security. Original PR #2305
Revert changes made to method signature to return back a ResultFuture instead of a Future. It seems to have introduced a breaking change in MSAL, instead of debugging this during release time, I rolled back part of the solution for the original google crash. In this PR i'm rolling back the whole fix for better tracking, will have a following PR to reintroduce the smaller fix into common to address the issue without adjusting method signatures that could affect msal or broker. Original PR #2305
Previously implemented a fix for common to address this bug https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2502607. Original common PR #2305, which has now been reverted. During release process in february, realized that the original fix introduced a break in MSAL. Not totally clear where the break was, but realized that parts of the fix that were causing the break were unnecessary. This PR is to add back the parts of the fix that would address the teams bug, without introducing the breaking change in MSAL and Broker (we don't change the method signatures in `OAuth2Strategy.requestAuthorization()` or `IAuthorizationStrategy.requestAuthorization()`). Instead of changing signature, we use a type check. Testing: Tested manually, was able to recover after throwing NPE Also ran common consumers pipeline check
Related Bug https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2502607
Related PR https://github.com/AzureAD/ad-accounts-for-android/pull/2690
Teams is seeing a crash during
LocalMSALController.onFinishAuthorizationSession()
, where we occasionally get aNullPointerException
onmAuthorizationStrategy.completeAuthorization()
. It's unclear why this happens, but the root issue that such an exception should be routed as a BaseException and sent back as a command result. This PR handles this by routing the exception through the command result if it happens during the callbackAlso add a check to see if the authorization future is initialized and waiting, provide an exception for it if we run into the NPE.
E2E testing
I tested this with MSALTestApp by throwing a NPE explicitly in complereAuthorization() and caught the exception, routing through to a command result.