Skip to content

PatchNamespacedCustomObjectWithHttpMessagesAsync fails with the latest nuget 2.0.29. #476

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

Closed
aronip opened this issue Aug 24, 2020 · 3 comments · Fixed by #506
Closed

PatchNamespacedCustomObjectWithHttpMessagesAsync fails with the latest nuget 2.0.29. #476

aronip opened this issue Aug 24, 2020 · 3 comments · Fixed by #506

Comments

@aronip
Copy link

aronip commented Aug 24, 2020

As per PR #385, there has been a change in PatchNamespacedCustomObjectWithHttpMessagesAsync method to use JsonPatch as the PatchType, instead of MergePatch which was the behavior before.

image

Due to this in our existing implementation, we are hitting the below error while patching a namespaced custom object:
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"json: cannot unmarshal object into Go value of type jsonpatch.Patch","reason":"BadRequest","code":400}.

The client expects that PatchType must be JsonPatch now, but in our scenario we need the support for MergePatch. Would it be possible to revert to the existing behavior, prior to #385? Or, can PatchType be added as an input for these methods?

@brendandburns
Copy link
Contributor

Yeah, this is unfortunate, I would have suggested passing in the Content-Type in the custom headers parameter, but looking at the generated code, the content-type is overridden if if it is passed in.

That seems like a bug in AutoRest (the code generator in question) since at this point you can't customize the content-type. I'll follow up with that project and see if we can fix things.

@gaurav137
Copy link

gaurav137 commented Oct 9, 2020

@brendandburns any update on AutoRest project making this fix? We were also looking at picking up #493 (throw on 401 error) when its available but looks like at that point we also need to have this issue resolved so that we can pick the latest nuget.

@brendandburns
Copy link
Contributor

I checked w/ the AutoRest team, it looks like a fix may not be forthcoming quickly, so I will see about manually editing this file to revert to the default behavior while we look to see if there is a more permanent fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants