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
"Kubernetes Resource Mistype" error with CoreV1API.deleteNamespace #4
Comments
Hey, thanks for writing in. The inconsistent response bodies on deletion of certain Kinds is something I've run into previously. I used to use a silly workaround for it: policyApi
.namespace(unusedBudget.namespace)
.deletePodDisruptionBudget(unusedBudget.name, {})
.catch(err => 'TODO: deletion has a response parsing error') I added a fix at some point and was able to remove my workarounds when updating to I'll have to revisit and see what is going on with those specific kinds.. |
Ok, my previous workaround was less forward-thinking than I hoped: deno-kubernetes_apis/generation/codegen-mod.ts Lines 16 to 19 in 4c2ef77
There's a bunch more known Kinds that return the deleted resource. But the kubernetes java thread said that even the kinds that return the deleted resource will switch to returning just a Status if called again (e.g. if there wasn't a resource to delete). So the actual correct fix must be returning e.g. This would be a breaking change of course! Too bad the openapi doesn't seem to have any of this info, it would be nice to know which delete methods never return the deleted resources. References:
|
Yeah, I've ended up just creating a variant which returns
Yeah, although it's worth it IMO, seeing as the only time you'll get a Alternatively, it could be done as an additional option, e.g.,
Yeah, it seems that every issue raised against the kubernetes/kubernetes project to fix the docs has just gone stale 😢 I guess there's a few options:
I'm not convinced that (1) is a good option, as there's inevitably going to be missing entries. E.g., CRDs also exhibit this behaviour, but aren't included in the (2) will provide the most consistent API, although it will require a breaking change (and consumers may need to add their own type assertions to narrow types) (3) feels really hacky (I'm guessing they chose it for Java because of the lack of union types) and it'd make it harder to work out whether a resource is deleted or just in the process of being deleted, although it avoids breaking changes. (4) also avoids breaking changes, but is the most complex to implement and use (e.g., I think it'd need to be clearly documented) I'd be happy to raise a PR to implement one of these options, if you'd like. |
hey :) got a similar issue when i tried to delete a service with
|
I'm also hit by this issue: Error: Kubernetes Resource Mistype: Expected "v1/Status", but was given "argoproj.io/v1alpha1/Application". This is likely a library bug. Feel free to file an issue with a stack trace. |
Thanks for bumping this issue. Clearly it comes up pretty often to users 😢 A workaround would be swallowing the library bug errors when you call delete APIs: await api.deleteWhatever(...).catch(err => err.message.includes("library bug") ? null : Promise.reject(err)) To be frank I've simply done The proper fix will be returning |
I have a patch to address this released in I also dug into the Kubernetes apiserver code to check if |
Hey, thanks for the work you've done on this project!
I've encountered an issue with a couple of the delete methods on the API classes:
Namespace deletion is asynchronous, so the first API call returns a
v1/Namespace
object (withphase: Terminating
), then only returns av1/Status
object when the deletion is complete.Unfortunately, the API Reference doesn't explain/document this behaviour.
I've also encountered the same issue on the
ApiextensionsV1Api.deleteCustomResourceDefinition
method.The text was updated successfully, but these errors were encountered: