Inconsistency in ApiException’s response (missing responseBody) #2750
Description
Describe the bug
While calling DynamicKubernetesApi’s create method with data which contains invalid information like
"spec": {
"image": 1,
}
a 422 status code is returned as usual, but with a very strange message format.
Referring back to the inconsistency I wrote in the title, I meant:
1, The content of the getResponseBody() method is empty, which is usually not the case for other responses.
2, The content of the getMessages() method is in a strange format (likely created by the V1Status class's own toString implementation), not meant to be processed.
The content of the detailMessage property is the following:
class V1Status {\n apiVersion: v1\n code: 422\n details: class V1StatusDetails {\n causes: [class V1StatusCause {\n field: spec.cronSpec\n message: Invalid value: \"integer\": spec.cronSpec in body must be of type string: \"integer\"\n reason: FieldValueTypeInvalid\n }, class V1StatusCause {\n field: spec.image\n message: Invalid value: \"integer\": spec.image in body must be of type string: \"integer\"\n reason: FieldValueTypeInvalid\n }, class V1StatusCause {\n field: spec.replicas\n message: Invalid value: \"string\": spec.replicas in body must be of type integer: \"string\"\n reason: FieldValueTypeInvalid\n }]\n group: stable.example.com\n kind: CronTab092293eb-bf87-42e9-8514-b2dac50fb747\n name: new-cron-object092293eb-bf87-42e9-8514-b2dac50fb747\n retryAfterSeconds: null\n uid: null\n }\n kind: Status\n message: CronTab092293eb-bf87-42e9-8514-b2dac50fb747.stable.example.com \"new-cron-object092293eb-bf87-42e9-8514-b2dac50fb747\" is invalid: [spec.cronSpec: Invalid value: \"integer\": spec.cronSpec in body must be of type string: \"integer\", spec.image: Invalid value: \"integer\": spec.image in body must be of type string: \"integer\", spec.replicas: Invalid value: \"string\": spec.replicas in body must be of type integer: \"string\"]\n metadata: class V1ListMeta {\n _continue: null\n remainingItemCount: null\n resourceVersion: null\n selfLink: null\n }\n reason: Invalid\n status: Failure\n}
The raw exception:
Received an ApiException{exceptionMessage=class V1Status {
apiVersion: v1
code: 422
details: class V1StatusDetails {
causes: [class V1StatusCause {
field: spec.cronSpec
message: Invalid value: "integer": spec.cronSpec in body must be of type string: "integer"
reason: FieldValueTypeInvalid
}, class V1StatusCause {
field: spec.image
message: Invalid value: "integer": spec.image in body must be of type string: "integer"
reason: FieldValueTypeInvalid
}, class V1StatusCause {
field: spec.replicas
message: Invalid value: "string": spec.replicas in body must be of type integer: "string"
reason: FieldValueTypeInvalid
}]
group: stable.example.com
kind: CronTab092293eb-bf87-42e9-8514-b2dac50fb747
name: new-cron-object092293eb-bf87-42e9-8514-b2dac50fb747
retryAfterSeconds: null
uid: null
}
kind: Status
message: CronTab092293eb-bf87-42e9-8514-b2dac50fb747.stable.example.com "new-cron-object092293eb-bf87-42e9-8514-b2dac50fb747" is invalid: [spec.cronSpec: Invalid value: "integer": spec.cronSpec in body must be of type string: "integer", spec.image: Invalid value: "integer": spec.image in body must be of type string: "integer", spec.replicas: Invalid value: "string": spec.replicas in body must be of type integer: "string"]
metadata: class V1ListMeta {
_continue: null
remainingItemCount: null
resourceVersion: null
selfLink: null
}
reason: Invalid
status: Failure
}, code=422, responseHeaders=, responseBody=null}
Client Version
17.0.2 (but it was also tried out on 18.0.1 and the issue is still reproducible)
Kubernetes Version
1.27
minikube version: v1.30.1
Java Version
Java 17
To Reproduce
The DynamicKubernetesApi’s create method is called with the following DynamicKubernetesObject:
{"kind":"CronTab585ebab4-bf11-4c63-8a0b-2ed1bd0b444f","apiVersion":"stable.example.com/v1","metadata":{"name":"new-cron-object585ebab4-bf11-4c63-8a0b-2ed1bd0b444f","namespace":"default"},"spec":{"cronSpec":1,"image":1,"replicas":"string"}}
Expected behavior
It would be nice to receive a valid (stringified) JSON back.
Server:
- OS: MacOS Ventura 13.4, Linux
- Environment: Executed within a container in the cluster