maxRequestsPerSocket request-count recycling visibility gap

Direct answer

Fastify does not change the Node.js maxRequestsPerSocket default unless you pass it explicitly. It inherits whatever the running Node.js http.Server applies. The supplied research does not verify the exact Node.js major release that changed the default from Infinity; treat any specific version claim as pending review. Fastify version alignment matters indirectly: a newer Fastify release usually requires a newer Node.js minimum, so the inherited socket behavior follows the Node.js runtime, not the Fastify major version itself.

Fastify hooks run per request, not per socket, so they cannot by themselves expose a cumulative socket request tally. You can, without changing Fastify core, attach to fastify.server, key a counter on request.raw.socket in onRequest, and read it when the socket emits close.

HTTP keep-alive and database plugin pool recycling do not operate on the same underlying connection. The HTTP socket connects the client to Fastify; the pool connects Fastify to the database. They are separate TCP links. Mismatched timeouts can create indirect backlog or idle database clients, but Node.js does not recycle an HTTP socket because a database client became idle.

Confirmed facts vs likely explanation

Item	Status	Note
Fastify exposes fastify.server	Confirmed	Native Node.js http.Server instance.
maxRequestsPerSocket default history	Unverified	Brief states historical default was Infinity; exact changing release requires current Node.js docs.
Per-socket request tally in Fastify public API	Confirmed absent	No built-in counter or timer is exposed.
Database pool vs HTTP socket separation	Confirmed	Plugins manage server-to-DB connections independently.

Verification steps for this case

1. Run node --version and npm ls fastify in the affected deployment.
2. Inspect the inherited values:

const fastify = require('fastify')()
console.log('maxRequestsPerSocket:', fastify.server.maxRequestsPerSocket)
console.log('keepAliveTimeout:', fastify.server.keepAliveTimeout)

1. Instrument socket tallies without core changes:

const socketCounts = new Map()

fastify.addHook('onRequest', (request, reply, done) => {
  const socket = request.raw.socket
  socketCounts.set(socket, (socketCounts.get(socket) || 0) + 1)
  done()
})

fastify.server.on('connection', (socket) => {
  socket.on('close', () => {
    const count = socketCounts.get(socket)
    if (count !== undefined) {
      console.log('socket closed after requests:', count)
      socketCounts.delete(socket)
    }
  })
})

1. Compare database plugin idle/timeout settings against keepAliveTimeout to rule out pool-induced backlog masquerading as socket exhaustion.

Assumptions and uncertainty

• This assumes HTTP/1.1 keep-alive. HTTP/2 uses multiplexed streams over a single connection, so per-socket request counting behaves differently.
• Do not mutate fastify.server settings after server startup in production without testing graceful shutdown; Fastify's abstraction may not track manual changes.
• The exact Node.js major release that altered maxRequestsPerSocket defaults is not confirmed here; provide your Node.js major version if you need a version-specific answer.

Missing diagnostic detail: What Node.js major version is running in the affected environment?