Breaking change: Accept header is missing in generated client

[bkoelman]

What are you generating using Kiota, clients or plugins?

API Client/SDK

In what context or format are you using Kiota?

Nuget tool

Client library/SDK language

Csharp

Describe the bug

After updating from 1.25.1 to 1.26.1, HTTP Accept headers are no longer being generated in some cases.

For example, when an endpoint defines multiple responses, where only some of them have a content type. In that case, the client should send an Accept header, to enable the server to respond with all possible statuses.

Expected behavior

Client sends an Accept header if at least one response defines a content type.

How to reproduce

Open API description file

{
  "openapi": "3.0.4",
  "paths": {
    "/api/tags/{id}/relationships/todoItems": {
      "post": {
        "summary": "Adds existing todoItems to the todoItems relationship of an individual tag.",
        "operationId": "postTagTodoItemsRelationship",
        "responses": {
          "204": {
            "description": "The todoItems were successfully added, which did not result in additional changes."
          },
          "400": {
            "description": "The request body is missing or malformed.",
            "content": {
              "application/vnd.api+json; ext=openapi": {
                "schema": {
                  "$ref": "#/components/schemas/errorResponseDocument"
                }
              }
            }
          },
          "404": {
            "description": "The tag or a related resource does not exist.",
            "content": {
              "application/vnd.api+json; ext=openapi": {
                "schema": {
                  "$ref": "#/components/schemas/errorResponseDocument"
                }
              }
            }
          },
          "409": {
            "description": "The request body contains conflicting information or another resource with the same ID already exists.",
            "content": {
              "application/vnd.api+json; ext=openapi": {
                "schema": {
                  "$ref": "#/components/schemas/errorResponseDocument"
                }
              }
            }
          },
          "422": {
            "description": "Validation of the request body failed.",
            "content": {
              "application/vnd.api+json; ext=openapi": {
                "schema": {
                  "$ref": "#/components/schemas/errorResponseDocument"
                }
              }
            }
          }
        }
      }
    },
  }
}

Kiota Version

1.26.1

Latest Kiota version known to work for scenario above?(Not required)

1.25.1

Known Workarounds

No response

Configuration

No response

Debug output

No response

Other information

No response

[baywet]

Hi @bkoelman
Thank you for using kiota and for reaching out.

The accept header is driven by the response media type of the successful responses.

In the example you've provided, the expected response is a 204, which does not have a response body.

Wouldn't it be strange to set the accept header with the media type of error responses?

[bkoelman]

The accept header is driven by the response media type of the successful responses.

I haven't encountered that before. Can you point me to the spec that defines this?

Wouldn't it be strange to set the accept header with the media type of error responses?

Why? The schema type for error responses is defined too, so it may as well have a different media type I suppose.

[bkoelman]

Using media types in error responses is described as a best practice at https://www.speakeasy.com/openapi/responses/errors#defining-error-responses-in-an-openapi-document.

Here's a use case. Consider an endpoint that returns 204 without a body on success. For each error, multiple content types are defined, defaulting to plaintext for interactive usage from the console. As kiota needs JSON to produce an exception, it should indicate so via an Accept header.

[baywet]

I haven't encountered that before. Can you point me to the spec that defines this?

If you mean "kiota spec", I don't think we have anything public. If you mean OAS, it's really a description of "everything that can happen with the API", they usually don't provide guidance for tooling authors. (I've asked the TDC repeatedly about such kind of guidance for other aspects)

To help understand the recent change, I tracked down the issue that lead to it #6413 (and associated PR) for context.

Why? The schema type for error responses is defined too, so it may as well have a different media type I suppose.

Because it could lead to 415 responses in some cases, couldn't it? Or the inability for the client to parse the successful response. Unless maybe we come up with some kind of routine to give a bigger priority to successful responses media types.

Let me know if you have any additional comments or questions.