[Bug]: PATCH /api/user/registration/{userId} does not merge arrays properly

[JoshTheHero]

What happened?

When you make the Update Registration call with the App Id in the URI(PATCH /api/user/registration/{userId}/{applicationId}), then it works as expected. However if you only provide the App Id in the request body(which the API doc says is okay) and NOT in the URI(/api/user/registration/{userId}/ ), then whenever you make the PATCH call it will overwrite the arrays(such as registration.data or .roles) on the registration object with whatever is in the request body instead of appending to it. It seems like its doing a JSON Merge Patch(or a PUT) when it does not have the App Id in the URL of the API call. Video below is an example of it.

https://www.loom.com/share/14f3ceaf798e4b508594387c07607a0c

Version

1.56.0

Affects Versions

No response

Alternatives / Workarounds

Treat the PATCH call like a PUT and include the whole array when making a call

[robotdan]

I think the doc is wrong. You must provide the applicationId on the URL as far as I know.

Maybe we are just missing a validation step to ensure the user provided this URL parameter. If you do not provide the applicationId on the URL we will not have correctly loaded the current version to patch. My assumption is this the reason for the behavior.

My guess is this is a validation bug, and if so, the doc needs to be updated to better reflect that you cannot provide the applicationId in the request body, it must be a URL segment.

[mooreds]

I think the doc is wrong. You must provide the applicationId on the URL as far as I know.

@robotdan the comment here indicates that either is okay, but maybe that is wrong too?

[robotdan]

Not sure why that comment is there... but I do know that this line of code (linked below) is a @PreParameterMethod which runs before validation.

https://github.com/FusionAuth/fusionauth-app/blob/a7ed261bce05f806af9a16dc07b56b35cc1e2f7f/src/main/java/io/fusionauth/app/action/api/user/RegistrationAction.java#L117

So if the applicationId is not provided on the URL we will not have loaded the registration that is required to patch correctly.

That comment you mentioned could apply for PUT or PATCH and for PUT in theory it would not matter if it is provided on the URL or the request body - because for PUT we are assuming the caller is sending the current state of the User Registration.

My guess is the doc is wrong - but then we should probably be failing validation if we must have the applicationId on the URL. At least that is my assumption so far.