Hands-On Lab & Phase Exit Error matrix, correlation exercise, engineering challenges, oral exam, and completion checklist
Phase 13 - Professional Error Handling Volume 04 - Professional Backend
Architecture milestone implement
↓
trigger errors
↓
correlate logs
↓
verify contract
↓
explain architecture
Phase 13 creates one professional exception boundary and a correlation story that spans client response and server logs.
Hands-on lab The exit lab proves that TaskFlow has one coherent error boundary instead of a collection of framework-default responses.
Lab A - Add the error contract • Create ApiErrorResponse.
• Add TaskNotFoundException and ProjectNotFoundException.
• Update TasksService to throw domain-specific exceptions where context is known.
• Keep unknown exceptions re-thrown.
Lab B - Add global filter and request logging • Create ApiExceptionFilter using HttpAdapterHost.
• Create RequestLoggingInterceptor using Fastify request.id.
• Register both globally with APP_FILTER and APP_INTERCEPTOR.
• Verify successful responses expose x-request-id.
• Verify 4xx/5xx error bodies contain requestId.
Lab C - Error matrix Scenario Expected
Lab D - Correlation exercise • Trigger one failing request.
• Copy requestId from the JSON response.
• Find the matching NestJS log entry.
• Confirm the client response is sanitized while the log has diagnostic context.
• Remove any temporary route used to create an artificial 500.
Exercise levels Level Challenge
1 - Follow Implement the reference filter/interceptor and pass the smoke-test matrix.
2 - Modify Add a stable PROJECT_NOT_FOUND client handling branch in the Next.js API helper demo.
3 - Implement Add a Task title uniqueness rule inside one Project and map its P2002 conflict safely.
4 - Engineer Design an error-code naming convention for a future HRIS with payroll, leave, recruitment, and employee domains; explain which codes are public contracts and which diagnostics remain internal.
Architecture oral exam • Why should a global error filter not contain Task business rules?
• Why is requestId useful if the client never sees a stack trace?
• When should a service catch a Prisma error instead of relying on the global filter?
• Why is P2002 usually 409 but an unavailable database usually 500?
• What is the difference between a network failure and an API error response?
• Which data should never be written to logs even during debugging?
Phase exit checklist • all error responses have statusCode, code, message, requestId, timestamp, and path.
• validation details remain useful without exposing internals.
• Task/Project not-found failures have domain codes.
• known Prisma conflicts are translated safely.
• unknown errors return sanitized 500 responses.
• requestId correlates client response and server logs.
• successful responses expose x-request-id.
• NestJS production build passes.
• you can explain which layer owns classification, translation, formatting, and logging.
Figure 1 - Phase 13 complete architecture Request / Fastify request.id
↓
↓
↓
↓
↓
TaskFlow now has a professional error boundary that remains useful as authentication, authorization, and business rules become more complex.
Phase 14 will deepen Service & Business Logic Architecture: application invariants, cross-model rules, workflow methods, transactions where needed, orchestration vs persistence, and keeping controllers thin without turning services into giant “god classes.”
Hands On Lab and Phase Exit matters because it changes a real boundary in TaskFlow. The goal is to understand the inputs, owner, observable output, and failure modes before adding more abstraction.
Restate the goal of “Hands On Lab and Phase Exit” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: failure → typed/domain error → exception mapping → HTTP envelope → client handling. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: Error taxonomy + NestJS mapping layer/filters + structured error response with request IDs.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
{
"error": {
"code": "TASK_NOT_FOUND",
"message": "Task was not found",
"requestId": "req_..."
}
}Do not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.
Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.
Without copying the final source, create a second small scenario that applies “Hands On Lab and Phase Exit” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Add request/correlation IDs to responses and logs.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Catching everything inside each controller
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.