Problem
500 responses today go through Fastify's default error handler, which returns the error message in the response body but does not log the stack to stdout/pm2. During #309 (intermittent 500 on concurrent PUTs), we had to infer the thrown exception from the 91-byte response body because no stack trace was captured. That investigation took significantly longer than it needed to.
Fix
Register a fastify.setErrorHandler in src/server.js that:
- Logs
err.stack (plus request method/url/hostname) via request.log.error or console.error
- Delegates response shape to the default behavior (or reproduces it) so existing API contracts don't change
- Skips logging for expected
FastifyError subclasses that carry their own statusCode (validation errors, etc.) to avoid noise
Impact
Every future 500 in production gets a real stack trace. Near-zero runtime cost.
Problem
500 responses today go through Fastify's default error handler, which returns the error message in the response body but does not log the stack to stdout/pm2. During #309 (intermittent 500 on concurrent PUTs), we had to infer the thrown exception from the 91-byte response body because no stack trace was captured. That investigation took significantly longer than it needed to.
Fix
Register a
fastify.setErrorHandlerinsrc/server.jsthat:err.stack(plus request method/url/hostname) viarequest.log.errororconsole.errorFastifyErrorsubclasses that carry their own statusCode (validation errors, etc.) to avoid noiseImpact
Every future 500 in production gets a real stack trace. Near-zero runtime cost.