Bug: "content-type": "application/json" is set due to responses[].content type in spec, not requestBody.content, causing missing headers

[ehvattum]

Stumbled across quite a few issues when attempting to migrate a mono repo with many generated clients to
the 6.x version.

Example spec that causes missing content-type header. It is expected that a request to this operation
have the `"content-type" : "application/json".

   "/api/v1/Units/{id}/StartWash": {
    "post": {
        "tags": [
            "Units"
        ],
        "summary": "Start a wash",
        "description": "Start a wash on a unit",
        "operationId": "StartWash",
        "parameters": [
            {
                "name": "id",
                "in": "path",
                "required": true,
                "style": "simple",
                "schema": {
                    "type": "integer",
                    "format": "int32"
                }
            }
        ],
        "requestBody": {
            "content": {
                "application/json": {
                    "schema": {
                        "$ref": "#/components/schemas/StartWash"
                    }
                }
            },
            "required": true
        },
        "responses": {
            "200": {
                "description": "OK"
            },
            "401": {
                "description": "Unauthorized"
            }
        }
    }
}

[Xiphe]

Hi @ehvattum sorry to hear that v6 is causing trouble.

I'm not sure I fully understand the issue. The issue title seems to imply that you already checked into this?

From what I understand, the problem is that a request send to StartWash is missing it's content-type header. Even though it should be "application/json" as described under "requestBody".

But you have observed, that it's instead set by the responses?

Briefly looking into this now

[Xiphe]

(might be related to #597 ?)

[Xiphe]

On my end the above code generates something like

export function startWash(id: number, pet: Pet, opts?: Oazapfts.RequestOpts) {
  return oazapfts.fetchText(
    `/api/v1/Units/${encodeURIComponent(id)}/StartWash`,
    oazapfts.json({
      ...opts,
      method: "POST",
      body: pet,
    }),
  );
}

This does use the oazapfts.json helper which will set the "application/json" Content-Type by default. See https://github.com/oazapfts/oazapfts/blob/main/packages/runtime/src/runtime.ts#L118-L129

One breaking change we introduced with 5.0 is that it's now possible to overwrite the default "application/json" content-type header by specifying it via Oazapfts.RequestOpts so you might want to double-check if the issue comes from some default opts you're passing?

Let me know if this helps and if not it would be helpful if you could specify the issue a bit more.