User email cannot be removed even when optional

[ZhugeSong]

Checklist

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

Description

We've set up a database connection with optional emails using the Flexible Identifiers and Attributes features. When using the .NET SDK to try to remove a user's email, I haven't been able to get it to work correctly.

When using the API directly, you can set the email property to null, which will cause the field to be removed from the user. However, when we call the .NET SDK and set the Email property to null, that causes the SDK to omit the property from the request, which results in the field being unchanged on the user.

We alternatively tried setting the Email property to the empty string "", but that resulted in an error.

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "Payload validation error: 'Object didn't pass validation for format email: ' on property email (Email address of this user).",
  "errorCode": "invalid_body"
}

I do not necessarily want to change the behavior of sending null using the SDK since "leaving a property unchanged" is a useful feature to support patching an existing user. However, with null being used for that purpose and the empty string producing an error from the API, I am not sure how you should remove a user's email.

Reproduction

1. Create a database connection
2. Make email optional for users
3. Create a user on that connection with some email
4. Set up a .NET project using the Auth0 .NET SDK
5. Use the SDK to make a user update request with Email set to null
6. Observe email is unchanged (reasonable result, but means I cannot remove the email)

Additional context

No response

auth0.net version

7.39.0

.NET version

8

[kailash-b]

Hi @ZhugeSong 👋
Thanks for reaching out!

In our auth0.net SDK, we block fields that are set to NULL, and hence, the email that was set to NULL doesn’t get updated.

Why do we do that?

We use the User models for creating and updating User information.

Let’s assume a case where there is a change in the email address of a user. The user would just set the new email address to the UserUpdateRequest model and use it to make a PATCH call. Now, if we look at the UserUpdateRequest only the email address field is updated, while the rest of the string fields (like PhoneNumber) are NULL since NULL is the default for a string in C#.

If we do not exclude these NULLs, the PATCH request would override all fields while it is actually intended to update only the email. To avoid these scenarios, we exclude these NULL values.

In this particular case, where the user is actually trying to set the value to NULL, we are unable to distinguish whether it is the user who has explicitly set the value to NULL or if it is there since the default value is NULL.

Unfortunately, this scenario/use case is not supported in our SDK at the moment. We do have an item in the backlog to see how best we can support this.

As a workaround, you could directly make the updates on the Management Dashboard. If the number of such updates is very high, you might want to write your code snippet that will directly update the details as a one-time effort.

[ZhugeSong]

As I mentioned in my ticket, I understand why null behaves the way it does, and would like to continue to have that behavior for patch requests. I was just looking for a solution for when I want to remove an email using the SDK. Based on your comment, it sounds like that is simply not supported by the SDK and I'll need to call the API directly so I can supply null explicitly.

Is there a timeline as to when this issue will be addressed? I would prefer not to have to maintain duplicate API calls that the SDK should already be able to perform for me, as it's my understanding that the SDK provides other useful features like maintaining tokens.

[kailash-b]

@ZhugeSong We are indeed looking at some major updates to the SDK, and this issue is one of the things we want to resolve.
While I can assure you that we are working to have this update in place as soon as possible, unfortunately, I cannot provide a specific timeline for when it will be available.

[ZhugeSong]

All right, I'll see what I can do to work around it. I'll leave this issue open until it can be resolved. Thanks for the information.