CodeVetter · Repo Unpack · Behavior traces
fastify/fastify
Three concrete core flows were followed through source: startup and listening, request handling and reply serialization, and shutdown. Injection provides another entry into the same handler after readiness. The database write example illustrates an application-owned persistence boundary rather than an implemented core store. These are source traces, not runtime observations.
- Startup begins fastify() → processOptions → buildRouting/build404 → wrapRouting → createServer → SchemaController construction.
- Plugin boot installs Avvio → override; override calls registerPlugin, then either reuses the parent or constructs an inherited child with copied scoped facilities.
- Promise listening follows listen → listenPromise → ready → transport server.listen; success resolves a logged address.
- For localhost, listening continues through multipleBindings → dns.lookup → additional server instances → onListenHookRunner.
- Request handling follows routeHandler → Request/Reply creation → onRequestHookRunner → runPreParsing → handleRequest.
- After parsing, handler → preValidationCallback → validateSchema → validationCompleted → preHandlerCallback → context.handler; results use wrapThenable or reply.send.
- Object reply serialization follows preSerializationHook → preSerializationHookEnd → serializer selection → onSendHook → onSendEnd.
- Error sending enters onErrorHook; handleError selects the current or next inherited error handler, invokes it, and falls back to serialized transport output.
- Shutdown marks closing, closes routes, runs preClose, handles configured forced socket closure and available HTTP/2 session cleanup, then calls server.close unless an unstarted custom serverFactory instance takes the nextTick completion branch.
- The documented persistence flow is register Redis plugin → POST /foo → redis.set(req.body.key, req.body.value) → completion reply; it is an example integration.