Summary

When a Reply type is explicitly specified, the send() method now requires a payload argument instead of making it optional. This prevents silent bugs where developers forget to send the expected response type.

Closes #5534

Changes

• Added SendArgs<ReplyType> helper type in types/type-provider.d.ts to determine payload requirement
• Updated send() method signature in types/reply.d.ts to use spread parameters with SendArgs
• Updated existing type tests to reflect new signature
• Added new test cases verifying:
  • send() without arguments errors when Reply type is specified
  • send() without arguments is valid when Reply is void, undefined, or unspecified

Behavior

Note on undefined vs void: When using HTTP status code mappings like { 204: undefined }, the undefined gets converted to unknown via UndefinedToUnknown in type-provider.d.ts. This means send() is optional but send({}) is also allowed. Use void instead of undefined if you want stricter "no payload allowed" semantics.

Example

// Before: no error when forgetting to send payload
server.get<{ Reply: { test: boolean } }>('/', (req, reply) => {
  reply.send() // oops, forgot the payload - no TypeScript error
})

// After: TypeScript error
server.get<{ Reply: { test: boolean } }>('/', (req, reply) => {
  reply.send() // Error: Expected 1 argument, but got 0
  reply.send({ test: true }) // OK
})

AI Assistance Disclosure

I used Codex to review the changes, sanity-check the implementation against existing patterns, and help spot potential edge cases.