javascript: [release-1.x] Patch namespace secret trigger an error due to unsupported media type
Describe the bug
When trying to use patchNamespacedSecret method on release-1.x branch the following error is raised:
Error: None of the given media types are supported: application/json-patch+json, application/merge-patch+json, application/strategic-merge-patch+json, application/apply-patch+yaml
at ObjectSerializer.getPreferredMediaType (ObjectSerializer.js:1760:1)
at CoreV1ApiRequestFactory.patchNamespacedSecret (CoreV1Api.js:8653:1)
at ObservableCoreV1Api.patchNamespacedSecret (ObservableAPI.js:9211:1)
at ObjectCoreV1Api.patchNamespacedSecret (ObjectParamAPI.js:2661:1)
//...
** Client Version ** release-1.x
** Server Version ** 1.24.3
To Reproduce Sample code triggering the error:
const coreV1 = new CoreV1Api(config);
coreV1.patchNamespacedSecret(
{
namespace: "default",
name: "my-secret",
body: {"tls.crt": "newValue"},
}
)
Also kind of related to this issue, I think we are missing a way to instruct patchNamespacedSecret which patch strategy we expect it to use. For example in the above example I expect it to use application/merge-patch+json but have no way right now to provide the patch strategy.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 1
- Comments: 22 (12 by maintainers)
Commits related to this issue
- Add supportedMediaTypes needed for kubernetes client https://github.com/kubernetes-client/javascript/issues/893 — committed to dleehr/openapi-generator by dleehr 10 months ago
- Add supportedMediaTypes needed for kubernetes client (#16386) * Add supportedMediaTypes needed for kubernetes client https://github.com/kubernetes-client/javascript/issues/893 * Add generated f... — committed to OpenAPITools/openapi-generator by dleehr 10 months ago
@mstruebing The middleware change is actually unnecessary. The client is already determining what the Content-Type should be for the request (an enhancement over 0.x), but the generated ObjectSerializer was blocking that. Updating the generated ObjectSerializer code was the only fix needed for 1.0.0-rc3. So I think regenerating with openapi-generator will fix it here.
I hand-patched
node_modules/@kubernetes/client-node/dist/gen/models/ObjectSerializer.jsafter installing 1.0.0-rc3 and now I’m able to successfullypatchNamespacedSecret,patchNamespacedServiceAccount, etc.I believe in the past we supplied a custom ObjectSerializer, but I agree that it’s cleaner to just contribute to the generator instead.
Looking forward to the next rc since this should unblock a ton of routes!
I was able to get
patchoperations working in 1.0.0-rc3 with a minor edit to the generatedObjectSerializer.js. The code that needs to be changed is in https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/typescript/model/ObjectSerializer.mustache, so I’ve opened a PR on that project to support the additional media types: https://github.com/OpenAPITools/openapi-generator/pull/16386Edit: I did try to fix this with middleware but debugging the operation proved that the operation was failing before it even got to my middleware. Issue is that ObjectSerializer doesn’t support any of the the candidate media types for patching.
@jeromy-cannon this issue is from the 1.x releases, which included a workaround fix in 1.0.0-rc4
if you are experiencing this on a v0.x.x release, we may want to open a separate issue for tracking it as the 0.x and 1.x working branches are separate.
iirc one 0.x release approach to this issue was the KubernetesObjectAPI which doesn’t include all the same functionality yet on the 1.x branch, but should allow handling patch media types on 0.x releases
also, it would help for repro if you could include the exact media type and what method call you are expecting to use- is it
application/merge-patch+jsonas mentioned in the start of the thread?@clintonmedbery good point that item should be updated for clarity- the generator we are using is the new
typescriptgenerator that is still in development withnode-fetchselected as theframeworkconfig option it’s an attempt to merge the various typescript client generators, which could hopefully one day give us an easy upgrade path to native fetch and potentially supporting other frameworks we should probably update that in the main thread for clarity since right now it’s only in the migration doci see 2 related issues here: we don’t have a clear pattern or example for providing a custom patch strategy (this should be doable with the current requestContext middleware), and that some generated code has missing media types. Both appear to come from a disconnect in how the typescript generator creates the allowlist of media types and the swagger spec