Inconsistency in ApiException’s response (missing responseBody)

[Dorban29]

trafficstars

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

[Dorban29]

@brendandburns can I get a status about the progress of this issue?

[brendandburns]

We'd be happy to take a PR with a unit test that demonstrates the issue and a fix.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.