fix(openapi): always set requestBody.required to true when schema.body exists

[bas0N]

Fastify requires a body when schema.body is defined, even if all properties are optional. This ensures the OpenAPI spec correctly reflects Fastify's runtime behavior. This solves the issue #894

Problem

When a route has schema.body defined, Fastify requires that the request includes a body (at least {}), even if all properties inside that body are optional. However, the OpenAPI schema generated by @fastify/swagger was only setting requestBody.required to true when there were required properties inside the object. If the object had only optional properties, then requestBody.required was omitted, incorrectly marking the request body as optional.

This mismatch between the OpenAPI spec and Fastify's actual runtime behavior can mislead client code generators and API consumers.

Solution

This fix ensures that requestBody.required is always set to true when schema.body is defined, regardless of whether any properties inside the body are required. The fix sets required: true when creating the requestBody object in prepareOpenapiMethod, making it explicit that the body is required whenever a body schema is defined.

Example

Before (incorrect):

{
  "requestBody": {
    "content": {
      "application/json": {
        "schema": {
          "type": "object",
          "properties": {
            "hello": { "type": "string" }
          }
        }
      }
    }
  }
}

After (correct):

{
  "requestBody": {
    "required": true,
    "content": {
      "application/json": {
        "schema": {
          "type": "object",
          "properties": {
            "hello": { "type": "string" }
          }
        }
      }
    }
  }
}

Changes

• Set required: true when creating requestBody object in prepareOpenapiMethod
• Added test case for body with only optional properties
• Updated existing tests to expect required: true when schema.body is defined

Fixes the issue where the OpenAPI spec incorrectly showed requestBody as optional when Fastify actually requires it at runtime.

Checklist

• run npm run test && npm run benchmark --if-present
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Copilot]

Pull request overview

This PR fixes a mismatch between Fastify's runtime validation behavior and the generated OpenAPI specification for request bodies. When a route has schema.body defined, Fastify requires a body to be present (at least {}), even if all properties are optional. The fix ensures requestBody.required is always set to true when schema.body exists.

Key changes:

• Modified prepareOpenapiMethod to set required: true when creating the requestBody object
• Removed conditional required logic from resolveBodyParams that only set it when there were required properties
• Added comprehensive test coverage for the optional-properties case

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
lib/spec/openapi/utils.js	Sets requestBody.required = true unconditionally when schema.body is defined, removing the previous conditional logic based on required properties
test/spec/openapi/option.test.js	Adds new test case verifying that requestBody.required is true even when all body properties are optional
test/spec/openapi/schema.test.js	Updates existing test assertions to expect required: true in all requestBody objects

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bas0N]

@Fdawgs when you get a moment, could you please take a look at this PR? Thanks!

[ilteoood]

LGTM
but honestly I think that on the user perspective this could be considered as a breaking change.
Imagine if someone is generating TS types from the fastify's schema: objects that before were not required, now are flagged as required 🤔

[gurgunday]

lgtm

[bas0N]

@gurgunday @Fdawgs can we merge it ?

[gurgunday]

Not sure if we should count this as a bug fix or semver major

I lean towards the latter

Cc @mcollina