Crash when generating code due to unknown mime type

[papegaaij]

Since 1.8.0 Kiota crashes during generation. This seems to be caused by the changes from #3377. The openapi.json below results in error generating the client: One or more errors occurred. (Sequence contains no elements):

./kiota generate -d crash.json -l Go
crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: One or more errors occurred. (Sequence contains no elements)

When specifying --structured-mime-types "application/vnd.topicus.keyhub+json;version=67" generation succeeds, but with an incorrect mime type (see other ticket).

{
  "openapi": "3.0.1",
  "info": {
    "title": "Topicus KeyHub OpenAPI definition",
    "description": "Topicus KeyHub",
    "termsOfService": "https://topicus-keyhub.com",
    "version": "67"
  },
  "servers": [
    {
      "url": "https://keyhub.example.com/keyhub/rest/v1"
    }
  ],
  "paths": {
    "/account": {
      "post": {
        "operationId": "create_account",
        "requestBody": {
          "content": {
            "application/vnd.topicus.keyhub+json;version=67": {
              "schema": {
                "$ref": "#/components/schemas/authAccount"
              }
            }
          }
        },
        "responses": {
          "201": {
            "description": "default response",
            "content": {
              "application/vnd.topicus.keyhub+json;version=67": {
                "schema": {
                  "$ref": "#/components/schemas/authAccount"
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "authAccount": {
        "title": "authAccount",
        "type": "object",
        "properties": {
          "uuid": {
            "type": "string",
            "readOnly": true
          },
          "username": {
            "type": "string",
            "readOnly": true
          }
        }
      }
    }
  }
}

[baywet]

Hi @papegaaij,
Thanks for reporting this.
For reference, the other issue is #3668
Is this something you'd be willing to submit a pull request to address?

[papegaaij]

Unfortunately I'm very limited in my time at the moment, so I won't be able to work on this in the upcoming 2 months. Also, it's not entirely clear to me how this is all supposed to work after #3377 . As can be seen in the example, our application uses a vendor specific json format. We also support this same format in xml (not included in this example), which historically happens to be the default. So, it is essential that the client sets the accept header correctly. I would expect the client to always set a matching accept header when a response with content is defined. Matching in this case would be something the client understands, i.e. json.

[baywet]

Since we received multiple bugs on the content type/accept headers, I decided to prioritize this today.
I put together #3671 to address all those issues.

[papegaaij]

Great to hear and thanks for the quick response. 3 of those tickets were mine. I decided to create separate tickets, because I had the feeling that even though they probably originated from the same change, the changes required were different. I'd rather see a ticket closed as duplicate than have some part being overlooked in one large ticket.

I'll give your branch a try tomorrow. With a diff against the code generated by 1.7.0, it should be easy to spot any improvements or regressions.

[baywet]

No worries, the feedback is always appreciated.
We might consider doing a patch release since we had 2 other issues in the same area outside of the ones you've opened.

[papegaaij]

With main, Kiota still crashes with the same error when I specify --structured-mime-types application/vnd.topicus.keyhub+json (so without the ;version=67). IMHO this parameter should not be required for the mime type selection in Kiota. I would expect Kiota to match the unparameterized mime type against the full mime type in the openapi. The version is added in the generated sources now.

[baywet]

Thanks for testing the changes, I'll look into this specific case shortly.

[baywet]

Can you git a try to #3677 please? I believe these latest changes address this too.