When updating user it's not possible to unset optional fields

[Milena92]

Checklist

• [X] I have looked into the Readme and Examples, and have not found a suitable solution or answer.
• [X] I have looked into the API documentation and have not found a suitable solution or answer.
• [X] I have searched the issues and have not found a suitable solution or answer.
• [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• [X] I agree to the terms within the Auth0 Code of Conduct.

Description

When attempting to update a user to remove the nickname or name fields using the Auth0 Java SDK, passing null values does not unset these fields as expected. This behavior is inconsistent with the results when making direct API requests, where passing null successfully unsets these fields. Passing an empty string is not a viable workaround due to API validation constraints that prevent empty strings from being accepted for these fields.

Reproduction

1. Use the Auth0 Java Client to fetch a user.
2. Attempt to update the user, setting the nickname or first name field to null to indicate it should be unset.
3. Observe the result of the update operation and fetch the user again to verify if the field was unset.

Additional context

Passing null for the nickname or first name fields using the Auth0 Java Client does not unset these fields. The fields remain unchanged in the user's profile, indicating the null value is either not being serialized or not processed by the Auth0 Java Client in the same manner as direct API requests.

auth0-java version

2.1.0

Java version

21

[jimmyjames]

Thanks for the report @Milena92! Yes, this is an issue in this and other typed SDKs unfortunately. The problem is that in certain cases (like you described, to unset a field) we want to send null, but in the majority of cases we should never send null values, as it could inadvertently unset values. For example, if you want to just update a single field on an entity, if we send null values that means every field would have to be set to its current/desired value or it would be unset. I think if it's even possible to address this issue, we'd at a minimum need to start with splitting out request/response objects, instead of using a single domain for both request and response as we do today. But even then I'm not sure how we'd either selectively send nulls or ensure good DX when just trying to update a single field, for example.