[fadiroot]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

FastifyAdapter.reply() compares the Content-Type header with the exact string application/json. A JSON content type that carries parameters, such as application/json; charset=utf-8, is therefore treated as non-JSON when an error body is sent: the adapter logs

Content-Type doesn't match Reply body, you might need a custom ExceptionFilter for non-JSON responses

for a body that is JSON, and then overwrites the header with application/json, dropping the charset.

This is easy to hit because @Header() values are applied before pipes run, so a handler like

@Get(':id')
@Header('Content-Type', 'application/json; charset=utf-8')
find(@Param('id', ParseIntPipe) id: number) {}

logs the warning on every GET /abc.

The express adapter had the same check and was changed to startsWith('application/json') in 4f391c2; the fastify adapter was not updated, so the two adapters behave differently.

What is the new behavior?

reply() checks typeof contentType === 'string' && !contentType.startsWith('application/json'), matching the express adapter. Parameterised JSON content types are left alone; non-JSON content types are still replaced by application/json for error bodies.

Two unit tests cover both cases in fastify-adapter.spec.ts.

Does this PR introduce a breaking change?

• Yes
• No

Other information