requestTimeout enforcement varies across Node versions under concurrent connections

Timeout enforcement under concurrent sockets

Fastify forwards requestTimeout, keepAliveTimeout, and connectionTimeout directly to Node's HTTP server. Their defaults and enforcement points changed across Node major versions, making timeout-related latency under many open sockets version-sensitive. Because Fastify does not create threads per request, handlers, validation, and serialization all execute on the same event loop; CPU-bound work under concurrency directly increases tail latency without necessarily surfacing a distinct timeout error.

The framework provides no documented built-in queue or concurrency cap for individual route handlers, leaving in-flight work limits to the application, an upstream proxy, or process-level clustering. This raises an unresolved design question: when the event loop is saturated by concurrent requests, does timeout enforcement behave deterministically, or does it depend on Node version internals that are not visible through Fastify's option surface?

Which timeout option is most likely to produce version-sensitive latency under many open connections? How does the absence of built-in concurrency limiting interact with Node's timeout enforcement when the event loop is blocked? What is the recommended verification approach to isolate timeout behavior from event-loop blocking under sustained concurrent load?