Validation Errors, Testing & Debugging Diagnose failures by layer and prove malformed input never reaches persistence
Phase 12 - DTOs, Zod & Input Validation Volume 04 - Professional Backend
Architecture milestone invalid request
↓
validation failure
↓
Phase 12 introduces an explicit runtime validation boundary before controller and service logic.
What a validation failure should mean At this phase, invalid request shape should produce a client error before business logic executes. We keep NestJS's framework-provided validation response rather than designing a custom enterprise error envelope prematurely; Phase 13 will standardize application errors.
Figure 1 - Error ownership Malformed input
↓
↓
↓
client fixes request
Shape errors are client contract failures, not database failures.
Do not expose raw database errors for input mistakes If a malformed enum reaches Prisma and Prisma rejects it, the architecture has already allowed invalid external data too far into the system. The client should learn about contract errors at the boundary, not from persistence internals.
Diagnostic sequence Symptom First question
Invalid body still reaches service Is the global StandardSchemaValidationPipe registered?
Schema seems ignored Did @Body/@Param attach schema metadata?
Valid request fails Which exact Zod issue failed?
Unknown field is accepted Did you use a strict object schema?
PATCH {} succeeds Did the update schema refine against empty objects?UUID validation fails for real IDs Does the persisted ID format match the schema?
Testing malformed requests systematically • missing required field
• wrong primitive type
• blank string after trimming
• string above maximum length
• invalid UUID
• invalid enum member
• unknown property
• empty PATCH object
• valid null for a nullable field
• fully valid request still persists
Representative request matrix Request Expected layer Expected outcome
POST title=false schema 400POST projectId=bad-uuid schema 400PATCH {} schema 400PATCH status=ALMOST_DONE schema 400PATCH status=DONE service/Prisma success if Task exists400 says the request does not satisfy the endpoint contract. 404 says the request was structurally valid, but the referenced application resource was not found.
Validation Errors Testing and Debugging 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 “Validation Errors Testing and Debugging” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: untrusted input → runtime schema → validated value → business rule → safe operation. 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: Reusable create/update/query schemas integrated into NestJS request handling with useful validation errors.. 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.
const CreateTaskSchema = z.object({
title: z.string().trim().min(1).max(160),
priority: z.enum(["LOW", "MEDIUM", "HIGH"]),
});
const input = CreateTaskSchema.parse(requestBody);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 “Validation Errors Testing and Debugging” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Create a Zod schema and derive the TypeScript type instead of maintaining two divergent contracts.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Accepting arbitrary unknown keys into persistence calls
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.