- request_id generated or sanitized-propagated on every request (x-request-id)
- structured JSON logging (pino), one correlated line per request, injectable logger
- error envelope v2 { error: { statusCode, code, message, details? }, requestId }
- 5xx messages always generic; stack traces stay in server logs only
- explicit parseJson (zod) input validation hook at the API layer
- README HTTP contract section; deps justified in spec/tech.md
- all gates approved; verify.sh green
1.4 KiB
1.4 KiB
TESTS — F-003 HTTP foundation and request context
Unit — src/shared/tests/http-input.test.ts
- parseJson returns parsed value for valid input
- parseJson throws AppError 400 VALIDATION_ERROR with field issues for invalid input
- parseJson rejects non-object input when schema expects object
Composition — src/app/tests/http-foundation.test.ts
(app built with logger writing to an in-memory stream)
- GET /health responds 200 with x-request-id header (UUID shape)
- Valid incoming x-request-id is propagated: same value in response header and in the request log line
- Malicious x-request-id (bad charset / >128 chars) is replaced by generated UUID; log line carries the generated id
- Unknown route -> 404 envelope { error: { statusCode: 404, code: NOT_FOUND, message }, requestId } + x-request-id header
- Invalid JSON body on test route -> 400, envelope shape stable, requestId present
- Schema-invalid body on test route -> 400 code VALIDATION_ERROR, issues mention field path only
- Handler throwing Error('secret internal detail') -> 500 generic message, response body contains neither the message nor a stack; error log line contains requestId and stack
- Every request produces exactly one 'request completed' log line carrying the requestId
Manual / QA
- verify.sh green; live curl shows x-request-id header and JSON envelope on unknown route.