Errors, security, and observation
Design error middleware
Place one final four-argument error handler that maps known failures and hides internal details.
9 minute lesson
Start from the behavior you can observe. Validation returns a stable client error, while an unknown database failure returns a generic response with a request id.
Error middleware is part of the public API and the operational record; users and logs need different information. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
It is tempting to return stack traces and raw database messages to every client. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to classify expected failures, log structured internal context, and send a minimal stable external shape. Make the boundary explicit in code and in the project notes.
Tie the decision back to the larger job: Make failures safe for users and useful for operators without leaking secrets or losing requests silently. Record enough evidence that another developer can repeat the result without relying on your memory.
Trigger validation, authorization, missing-record, and unknown failures and compare client bodies with server logs. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.
Lesson completed