Content-type for RequestBody is forced to application/json even when explicitly says in requestBody to use multipart/form-data

[tjmonsi]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

4.7.0

Plugin version

7.6.1

Node.js version

16.17.1

Operating system

Linux

Operating system version (i.e. 20.04, 11.3, 10)

5.15.0-47-generic

Description

When writing an OpenAPI 3.0.0 specification of a request body content on a path, it forces the content-type to application/json even if it is set to multipart/form-data.

specification

{
  openapi: '3.0.0',
  info: {
    title: 'App',
    version: '0.0.1'
  },
  paths: {
    '/upload': {
      post: {
        summary: 'Upload',
        operationId: 'uploadData',
        requestBody: {
          content: {
            'multipart/form-data': {
              schema: {
                properties: {
                  file: {
                    type: 'string',
                    format: 'binary'
                  }                    
                }
              }                
            }
          }
        },
        responses: {
          200: {
            description: 'success',
            content: {
              'application/json': {
                schema: {
                  type: 'object',
                  properties: {
                    success: {
                      type: 'boolean'
                    }
                  }
                }
              }
            }              
          }
        }
      }
    }
  }
}

Steps to Reproduce

1. Clone https://github.com/tjmonsi/fastify-multipart-sample
2. install using npm i
3. Run using npm start
4. look at http://localhost:8080/docs
5. See that the dropdown doesn't show multipart/form-data and only shows application/json even if it is not part of the src/specification.js

Expected Behavior

Expected is that the Request Body is not application/json on the documentations page but multipart/form-data with the corresponding inputs (like file upload)

[climba03003]

You need to use static mode, otherwise the paths are override by @fastify/swagger.

[tjmonsi]

Hi @climba03003 Thanks for this. But for our usecase, we can't use static mode because the specification becomes too unwieldy if we put everything inside it (Thus, we opted to use import and export JS objects, with the occasional repeating of 4xx and 5xx errors on each path to complete the path documentation).

Static mode only accepts json and yaml - thus it may not work.

Tried it though on the simple setup that I made and it worked though. Although in relation to I think #667 , it becomes just a raw string input instead of a file upload feature.

Nevertheless, I am just curious as to why paths are being overrided by @fastify/swagger to just application/json even when explicitly showed to use multipart/form-data and why static worked. - this is even if it shows that when using components/requestBodies/[[referenceIdWithMulitpart]] as a $ref, and it shows in the json output of the documentation site, it still doesn't show the multipart

What I can say though that the logic is not hampered, unless I put type: "object" on the schema of the request body, which creates an error.

[climba03003]

Your case is not related to #667.

I am just curious as to why paths are being overrided

1. You are using fastify-openapi-glue which will helps you create routes based on the specification.
2. In dynamic mode, @fastify/swagger will helps you to fill paths information based on the created routes and the default requestBody content-type is application/json. You need to use consumes keyword to specify the requestBody content-type in dynamic mode.

By combining the above two situation, it is obvious your routes created fastify-openapi-glue will override by @fastify/swagger.

[tjmonsi]

I see.

But there is no consumes on OpenAPI 3.0 spec. In any case, thanks for letting me know about it