Fix NPE on Kotlin when callbacks returned a nullable value #344
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
On a previous PR, we introduced annotations to prevent the Kotlin compiler from guessing the nullability of the SDK's params and returned values by rather being explicit. This fix to the lint warnings was meant to improve the compatibility when this SDK was used in a Kotlin environment.
In the case of the callbacks that returned a
Void
type, those were annotated as "Non-null" and still returnednull
, given that the return value is not supposed to be used. However, Kotlin was checking its nullability on runtime crashing the app with an NPE when the value of a declared non-null variable was null.This was not caught in unit tests because we are not using Kotlin to compile this SDK nor run its tests. This only affects Kotlin codebases.
The fix was to roll back those changes in particular to the value that could be returned in a
BaseCallback
implementation, changing it back again toNullable
.References
Fixes #341
Testing
I've manually tested this on a kotlin app. Calling methods that make use of the
VoidRequest
(like the logout manager), anAuthenticationCallback
implementation that returns null (like passwordless/start), and a regular API call that returns a different type.This change adds unit test coverage
This change adds integration test coverage
This change has been tested on the latest version of the platform/language or why not
Checklist
I have read the Auth0 general contribution guidelines
I have read the Auth0 Code of Conduct
All existing and new tests complete without errors