Request Validation with Zod

Welcome to the first lesson of Request Validation and Express Error Architecture! Your ticket API already supports filtering, creation, partial updates, deletion, and nested comments backed by PostgreSQL. Now you’ll replace repeated route-level checks with one reusable validation pipeline built with Zod. You’ll define schemas for route parameters, query strings, ticket bodies, and comment bodies. Then you’ll connect those schemas to Express middleware, store normalized values in response.locals, and let one centralized error handler convert validation failures into consistent 400 VALIDATION_ERROR responses. Previously, each route manually inspected values such as request.query.status, request.body.title, and request.params.ticketId . Those checks worked, but they repeated parsing, trimming, enum validation, defaults, and error responses across several handlers. Zod moves those rules into reusable contracts so route handlers can focus on application behavior rather than raw input cleanup.

Understanding the Validation Flow

The completed request flow looks like this: text API Simulator ↓ Express request ↓ validateRequest(...) ↓ Zod schema parsing and normalization ↓ response.locals.validated ↓ Route handler ↓ Repository and PostgreSQL When validation fails, the request takes a different path: text Zod schema throws ZodError ↓ Express error flow ↓ errorHandler ↓ 400 VALIDATION_ERROR The important boundary is that repositories receive only values that have already passed structural validation. PostgreSQL existence checks still remain necessary for references such as requesterId and authorId .

Using the API Simulator as a Postman-Style Client

The API Simulator acts like a lightweight Postman-style HTTP client inside the course environment. It runs in the preview interface on port 3000, while the Express backend continues to listen on port 4000 . Set the base URL to: text http://localhost:4000 You can then select a method, enter an endpoint, add query parameters, and send JSON bodies. For example: text GET /api/tickets?status=open&priority=high&sortBy=createdAt&order=desc For request bodies, open Body, choose JSON, paste the payload, and use Beautify when you want the simulator to format inline JSON. Validation responses are especially useful in the simulator because you can inspect both the HTTP status and the field-specific details returned by the centralized error handler.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

The schemas live in src/schemas/ticket-schemas.ts. They import the existing status and priority constants instead of duplicating the allowed strings.

TypeScript

import { z } from "zod";

import {
  ticketPriorities,
  ticketStatuses,
} from "../domain/ticket.js";

import { z } from "zod";

import {
  ticketPriorities,
  ticketStatuses,
} from "../domain/ticket.js";

ticketStatuses already contains "open", "in_progress", and "closed". Reusing it ensures the domain model and request validation accept the same values.
ticketPriorities provides "low", "medium", and "high". If the domain changes later, the schema can continue deriving its enum from the shared source.
Zod performs runtime validation, while the TypeScript types in the domain file describe compile-time expectations. Together, they protect both external requests and internal code.

Ticket detail and nested comment routes depend on ticketId. The schema accepts both seeded identifiers such as tkt_1001 and generated identifiers such as tkt_<uuid>.

TypeScript

export const ticketIdParamsSchema = z.object({
  ticketId: z
    .string()
    .regex(
      /^tkt_[A-Za-z0-9-]+$/,
      "ticketId must use the tkt_<id> format",
    ),
});

export const ticketIdParamsSchema = z.object({
  ticketId: z
    .string()
    .regex(
      /^tkt_[A-Za-z0-9-]+$/,
      "ticketId must use the tkt_<id> format",
    ),
});

The outer z.object() matches the shape of request.params. Express provides route parameters as an object such as { ticketId: "tkt_1001" }.
The regular expression requires the tkt_ prefix followed by one or more letters, digits, or hyphens. This covers both deterministic seed IDs and UUID-based IDs.
A malformed path such as /api/tickets/not-a-ticket fails before findTicketById() is called. The database is not asked to look up an identifier that does not match the application’s format.

This schema checks the identifier’s shape, not whether the ticket exists. A valid-looking ID such as tkt_missing can still pass Zod and later produce 404 TICKET_NOT_FOUND.

The collection schema handles search, filters, sorting, and defaults.

TypeScript

export const ticketListQuerySchema = z.object({
  q: z.string().trim().min(1).max(100).optional(),
  status: z.enum(ticketStatuses).optional(),
  priority: z.enum(ticketPriorities).optional(),
  sortBy: z
    .enum(["createdAt", "priority"])
    .default("createdAt"),
  order: z.enum(["asc", "desc"]).default("desc"),
});

export const ticketListQuerySchema = z.object({
  q: z.string().trim().min(1).max(100).optional(),
  status: z.enum(ticketStatuses).optional(),
  priority: z.enum(ticketPriorities).optional(),
  sortBy: z
    .enum(["createdAt", "priority"])
    .default("createdAt"),
  order: z.enum(["asc", "desc"]).default("desc"),
});

q is optional, but when present it is trimmed and must contain between 1 and 100 characters. A value such as " payment " becomes "payment" before the repository receives it.
status and priority accept only the domain-supported values. A query such as status=waiting becomes a validation error rather than reaching SQL construction.
sortBy defaults to "createdAt" and order defaults to "desc". A plain GET /api/tickets therefore produces the complete normalized query object even though those values were omitted from the URL.
Zod’s parsed result is more useful than the raw query string because it already contains trimmed values, validated enums, and defaults.

The creation schema defines length limits, normalization rules, and defaults for optional fields.

TypeScript

export const createTicketBodySchema = z.object({
  title: z.string().trim().min(3).max(120),
  description: z.string().trim().max(1000).default(""),
  priority: z.enum(ticketPriorities).default("medium"),
  requesterId: z.string().trim().min(1),
});

export const createTicketBodySchema = z.object({
  title: z.string().trim().min(3).max(120),
  description: z.string().trim().max(1000).default(""),
  priority: z.enum(ticketPriorities).default("medium"),
  requesterId: z.string().trim().min(1),
});

title must contain between 3 and 120 characters after trimming. The normalized title is the value eventually inserted into PostgreSQL.
description defaults to an empty string and cannot exceed 1000 characters. Route handlers no longer need to repeat the conditional fallback used in the earlier implementation.
priority defaults to "medium" when omitted. Unsupported values such as "urgent" are rejected by the enum.
requesterId must be a non-empty trimmed string. Zod verifies its shape, while userExists() separately confirms that it references a real database row.

A body such as:

JSON

{
  "title": "Zod creation example",
  "requesterId": "usr_customer_1"
}

{
  "title": "Zod creation example",
  "requesterId": "usr_customer_1"
}

is normalized into:

JSON

{
  "title": "Zod creation example",
  "description": "",
  "priority": "medium",
  "requesterId": "usr_customer_1"
}

{
  "title": "Zod creation example",
  "description": "",
  "priority": "medium",
  "requesterId": "usr_customer_1"
}

The update schema allows only mutable fields and rejects empty patches.

TypeScript

export const updateTicketBodySchema = z
  .object({
    title: z.string().trim().min(3).max(120).optional(),
    description: z.string().trim().max(1000).optional(),
    priority: z.enum(ticketPriorities).optional(),
    status: z.enum(ticketStatuses).optional(),
  })
  .refine((value) => Object.keys(value).length > 0, {
    message: "At least one field is required.",
  });

export const updateTicketBodySchema = z
  .object({
    title: z.string().trim().min(3).max(120).optional(),
    description: z.string().trim().max(1000).optional(),
    priority: z.enum(ticketPriorities).optional(),
    status: z.enum(ticketStatuses).optional(),
  })
  .refine((value) => Object.keys(value).length > 0, {
    message: "At least one field is required.",
  });

Every field is optional because PATCH represents a partial update. Sending only { "status": "closed" } leaves the other ticket fields unchanged.
The schema includes only title, description, priority, and status. IDs, requester ownership, assignee data, and timestamps remain outside this general update contract.
.refine() applies a rule to the complete parsed object. It rejects {} because a partial update must still request at least one actual change.
The route no longer needs to build an empty patch object manually and check Object.keys() itself. That rule is now part of the reusable request contract.

Comment creation uses the same validation architecture.

TypeScript

export const createCommentBodySchema = z.object({
  authorId: z.string().trim().min(1),
  message: z.string().trim().min(1).max(500),
});

export const createCommentBodySchema = z.object({
  authorId: z.string().trim().min(1),
  message: z.string().trim().min(1).max(500),
});

authorId must contain a non-empty trimmed string. A later userExists() call determines whether the referenced author actually exists.
message must contain meaningful text after trimming and cannot exceed 500 characters.
A body containing "message": " " fails before the comment repository performs an INSERT.

Client-supplied authorId remains temporary scaffolding. Zod validation and database existence checks do not prove that the caller owns that identity.

The schema file exports inferred types alongside the runtime schemas.

TypeScript

export type TicketIdParams =
  z.infer<typeof ticketIdParamsSchema>;

export type TicketListQuery =
  z.infer<typeof ticketListQuerySchema>;

export type CreateTicketBody =
  z.infer<typeof createTicketBodySchema>;

export type UpdateTicketBody =
  z.infer<typeof updateTicketBodySchema>;

export type CreateCommentBody =
  z.infer<typeof createCommentBodySchema>;

export type TicketIdParams =
  z.infer<typeof ticketIdParamsSchema>;

export type TicketListQuery =
  z.infer<typeof ticketListQuerySchema>;

export type CreateTicketBody =
  z.infer<typeof createTicketBodySchema>;

export type UpdateTicketBody =
  z.infer<typeof updateTicketBodySchema>;

export type CreateCommentBody =
  z.infer<typeof createCommentBodySchema>;

z.infer derives a TypeScript type from the schema. The runtime validation contract and compile-time handler type therefore stay synchronized.
Defaults affect the inferred result. For example, the parsed CreateTicketBody has a definite description and priority, even when the original request omitted them.
Route handlers can read validated values with precise types instead of repeatedly casting raw Express input.

Creating Reusable Validation Middleware

The generic middleware lives in src/middleware/validate-request.ts.

TypeScript

interface RequestSchemas {
  params?: ZodType;
  query?: ZodType;
  body?: ZodType;
}

interface RequestSchemas {
  params?: ZodType;
  query?: ZodType;
  body?: ZodType;
}

Each middleware instance can validate any combination of params, query, and body.
All three properties are optional. A collection GET validates only its query, while a ticket PATCH validates both route parameters and a body.

The middleware parses only the supplied request sections.

TypeScript

export const validateRequest =
  (schemas: RequestSchemas): RequestHandler =>
  (request, response, next) => {
    const current = (
      response.locals.validated ?? {}
    ) as Record<string, unknown>;

    response.locals.validated = {
      ...current,
      ...(schemas.params
        ? { params: schemas.params.parse(request.params) }
        : {}),
      ...(schemas.query
        ? { query: schemas.query.parse(request.query) }
        : {}),
      ...(schemas.body
        ? { body: schemas.body.parse(request.body) }
        : {}),
    };

    next();
  };

export const validateRequest =
  (schemas: RequestSchemas): RequestHandler =>
  (request, response, next) => {
    const current = (
      response.locals.validated ?? {}
    ) as Record<string, unknown>;

    response.locals.validated = {
      ...current,
      ...(schemas.params
        ? { params: schemas.params.parse(request.params) }
        : {}),
      ...(schemas.query
        ? { query: schemas.query.parse(request.query) }
        : {}),
      ...(schemas.body
        ? { body: schemas.body.parse(request.body) }
        : {}),
    };

    next();
  };

schema.parse() both validates and transforms input. Trimming and defaults are applied before the parsed value is stored.
Conditional object spreads ensure the middleware does not parse sections for which no schema was supplied.
The parsed results are stored in response.locals.validated. This gives later middleware and handlers a shared per-request location for normalized values.
next() is called exactly once after every requested section has parsed successfully.

The middleware intentionally does not catch ZodError. A thrown error enters Express’s error flow and reaches the centralized four-argument error handler.

The current value is especially important for nested routes.

TypeScript

const current = (
  response.locals.validated ?? {}
) as Record<string, unknown>;

response.locals.validated = {
  ...current,
  ...(schemas.body
    ? { body: schemas.body.parse(request.body) }
    : {}),
};

const current = (
  response.locals.validated ?? {}
) as Record<string, unknown>;

response.locals.validated = {
  ...current,
  ...(schemas.body
    ? { body: schemas.body.parse(request.body) }
    : {}),
};

Consider nested comment creation:

text

POST /api/tickets/tkt_1001/comments

POST /api/tickets/tkt_1001/comments

The parent ticket router first validates and stores:

JSON

{
  "params": {
    "ticketId": "tkt_1001"
  }
}

{
  "params": {
    "ticketId": "tkt_1001"
  }
}

The child router then validates the body. It must add body without erasing params:

JSON

{
  "params": {
    "ticketId": "tkt_1001"
  },
  "body": {
    "authorId": "usr_agent_1",
    "message": "Validated nested comment"
  }
}

{
  "params": {
    "ticketId": "tkt_1001"
  },
  "body": {
    "authorId": "usr_agent_1",
    "message": "Validated nested comment"
  }
}

Merging the current object makes several validation stages cooperate across router boundaries.

The final error middleware in src/middleware/error-handler.ts recognizes ZodError.

TypeScript

import type { ErrorRequestHandler } from "express";
import { ZodError } from "zod";

import type { ErrorRequestHandler } from "express";
import { ZodError } from "zod";

Its validation branch converts Zod issues into a stable API response.

TypeScript

if (error instanceof ZodError) {
  response.status(400).json({
    error: {
      code: "VALIDATION_ERROR",
      message: "Request validation failed.",
      details: error.issues.map((issue) => ({
        path: issue.path.join("."),
        message: issue.message,
      })),
    },
  });
  return;
}

if (error instanceof ZodError) {
  response.status(400).json({
    error: {
      code: "VALIDATION_ERROR",
      message: "Request validation failed.",
      details: error.issues.map((issue) => ({
        path: issue.path.join("."),
        message: issue.message,
      })),
    },
  });
  return;
}

Every Zod validation failure becomes HTTP 400. Routes no longer need to produce their own slightly different INVALID_BODY or INVALID_QUERY responses.
issue.path.join(".") turns paths into readable strings such as title, status, or ticketId.
The issue message explains the violated rule without exposing internal stack traces or SQL information.
Returning afterward prevents the generic error branch from sending a second response.

A rejected short title might produce:

JSON

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request validation failed.",
    "details": [
      {
        "path": "title",
        "message": "Too small: expected string to have >=3 characters"
      }
    ]
  }
}

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request validation failed.",
    "details": [
      {
        "path": "title",
        "message": "Too small: expected string to have >=3 characters"
      }
    ]
  }
}

Errors that are not Zod validation failures continue through the generic branch.

TypeScript

console.error("Unhandled request error", error);
response.status(500).json({
  error: "Internal Server Error"
});

console.error("Unhandled request error", error);
response.status(500).json({
  error: "Internal Server Error"
});

Unexpected failures are logged on the server for diagnosis.
The client receives a generic 500 response rather than internal implementation details.
Validation errors and unexpected server errors now have clearly separate behavior.

Because errorHandler is registered after the routes in src/app.ts, errors thrown during validation or request handling can reach it.

The collection route now applies the query schema before its handler.

TypeScript

ticketRoutes.get(
  "/",
  validateRequest({ query: ticketListQuerySchema }),
  async (_request, response) => {
    const { query } = response.locals.validated as {
      query: TicketListQuery;
    };

    const result = await listTickets(query);

    response.setHeader(
      "X-Total-Count",
      String(result.total),
    );
    response.status(200).json(result.items);
  },
);

ticketRoutes.get(
  "/",
  validateRequest({ query: ticketListQuerySchema }),
  async (_request, response) => {
    const { query } = response.locals.validated as {
      query: TicketListQuery;
    };

    const result = await listTickets(query);

    response.setHeader(
      "X-Total-Count",
      String(result.total),
    );
    response.status(200).json(result.items);
  },
);

The handler no longer reads raw values from request.query.
query already contains validated filters and required sorting defaults.
The repository continues receiving the same TicketListOptions shape, so filtering, sorting, and X-Total-Count behavior remain unchanged.
Invalid enum values fail in middleware before listTickets() runs.

Ticket creation uses the body schema and its inferred type.

TypeScript

ticketRoutes.post(
  "/",
  validateRequest({ body: createTicketBodySchema }),
  async (_request, response) => {
    const { body } = response.locals.validated as {
      body: CreateTicketBody;
    };

    if (!(await userExists(body.requesterId))) {
      response.status(400).json({
        error: {
          code: "INVALID_REQUESTER",
          message:
            "requesterId does not reference an existing user.",
        },
      });
      return;
    }

    const ticket = await createTicket(body);

    response.setHeader(
      "Location",
      `/api/tickets/${ticket.id}`,
    );
    response.status(201).json(ticket);
  },
);

ticketRoutes.post(
  "/",
  validateRequest({ body: createTicketBodySchema }),
  async (_request, response) => {
    const { body } = response.locals.validated as {
      body: CreateTicketBody;
    };

    if (!(await userExists(body.requesterId))) {
      response.status(400).json({
        error: {
          code: "INVALID_REQUESTER",
          message:
            "requesterId does not reference an existing user.",
        },
      });
      return;
    }

    const ticket = await createTicket(body);

    response.setHeader(
      "Location",
      `/api/tickets/${ticket.id}`,
    );
    response.status(201).json(ticket);
  },
);

Zod handles title checks, trimming, description defaults, priority defaults, and requester shape.
userExists() remains necessary because schema validation cannot determine whether a database row exists.
The route preserves the existing 201 Created response and Location header.

A structurally valid value such as usr_missing passes Zod but still produces INVALID_REQUESTER.

Validating Detail and Update Routes

The detail route validates ticketId before performing a lookup.

TypeScript

.get(
  validateRequest({ params: ticketIdParamsSchema }),
  async (_request, response) => {
    const { params } = response.locals.validated as {
      params: TicketIdParams;
    };

    const ticket = await findTicketById(params.ticketId);

    if (!ticket) {
      response.status(404).json({
        error: {
          code: "TICKET_NOT_FOUND",
          message: "Ticket not found.",
        },
      });
      return;
    }

    response.status(200).json(ticket);
  },
)

.get(
  validateRequest({ params: ticketIdParamsSchema }),
  async (_request, response) => {
    const { params } = response.locals.validated as {
      params: TicketIdParams;
    };

    const ticket = await findTicketById(params.ticketId);

    if (!ticket) {
      response.status(404).json({
        error: {
          code: "TICKET_NOT_FOUND",
          message: "Ticket not found.",
        },
      });
      return;
    }

    response.status(200).json(ticket);
  },
)

Malformed IDs return 400 VALIDATION_ERROR.
Well-formed but absent IDs still reach the repository and return 404 TICKET_NOT_FOUND.

The PATCH route validates both sections in one middleware instance.

TypeScript

.patch(
  validateRequest({
    params: ticketIdParamsSchema,
    body: updateTicketBodySchema,
  }),
  async (_request, response) => {
    const { params, body } =
      response.locals.validated as {
        params: TicketIdParams;
        body: UpdateTicketBody;
      };

    const ticket = await updateTicket(
      params.ticketId,
      body,
    );

    if (!ticket) {
      response.status(404).json({
        error: {
          code: "TICKET_NOT_FOUND",
          message: "Ticket not found.",
        },
      });
      return;
    }

    response.status(200).json(ticket);
  },
)

.patch(
  validateRequest({
    params: ticketIdParamsSchema,
    body: updateTicketBodySchema,
  }),
  async (_request, response) => {
    const { params, body } =
      response.locals.validated as {
        params: TicketIdParams;
        body: UpdateTicketBody;
      };

    const ticket = await updateTicket(
      params.ticketId,
      body,
    );

    if (!ticket) {
      response.status(404).json({
        error: {
          code: "TICKET_NOT_FOUND",
          message: "Ticket not found.",
        },
      });
      return;
    }

    response.status(200).json(ticket);
  },
)

The handler receives a valid ticket ID and a non-empty normalized patch.
An empty {} body fails the schema refinement before updateTicket() runs.
The repository remains responsible only for persistence, not HTTP parsing.

The statistics route remains before /:ticketId.

TypeScript

ticketRoutes.get("/stats", async (_request, response) => {
  response.status(200).json(
    await countTicketsByStatus(),
  );
});

ticketRoutes.get("/stats", async (_request, response) => {
  response.status(200).json(
    await countTicketsByStatus(),
  );
});

This ordering is still required because Express evaluates routes in declaration order. If the dynamic route came first, the literal word stats could be treated as a ticket ID and then rejected by ticketIdParamsSchema.

Validation improves request boundaries, but it does not replace correct route organization.

Validating Nested Comment Routes

The parent ticket router validates ticketId, verifies the parent exists, and then passes control to the child router.

TypeScript

ticketRoutes.use(
  "/:ticketId/comments",
  validateRequest({ params: ticketIdParamsSchema }),
  async (_request, response, next) => {
    const { params } = response.locals.validated as {
      params: TicketIdParams;
    };

    if (!(await findTicketById(params.ticketId))) {
      response.status(404).json({
        error: {
          code: "TICKET_NOT_FOUND",
          message: "Ticket not found.",
        },
      });
      return;
    }

    next();
  },
  commentRoutes,
);

ticketRoutes.use(
  "/:ticketId/comments",
  validateRequest({ params: ticketIdParamsSchema }),
  async (_request, response, next) => {
    const { params } = response.locals.validated as {
      params: TicketIdParams;
    };

    if (!(await findTicketById(params.ticketId))) {
      response.status(404).json({
        error: {
          code: "TICKET_NOT_FOUND",
          message: "Ticket not found.",
        },
      });
      return;
    }

    next();
  },
  commentRoutes,
);

The malformed-ID check happens before the parent database lookup.
A valid but missing ticket receives 404.
For an existing parent, params remains stored in response.locals.validated when the request enters commentRoutes.

The child router adds body validation without replacing the parent parameters.

TypeScript

commentRoutes.post(
  "/",
  validateRequest({ body: createCommentBodySchema }),
  async (_request, response) => {
    const { params, body } =
      response.locals.validated as {
        params: TicketIdParams;
        body: CreateCommentBody;
      };

    if (!(await userExists(body.authorId))) {
      response.status(400).json({
        error: {
          code: "INVALID_AUTHOR",
          message:
            "authorId does not reference an existing user.",
        },
      });
      return;
    }

    const comment = await createComment(
      params.ticketId,
      body.authorId,
      body.message,
    );

    response.status(201).json(comment);
  },
);

commentRoutes.post(
  "/",
  validateRequest({ body: createCommentBodySchema }),
  async (_request, response) => {
    const { params, body } =
      response.locals.validated as {
        params: TicketIdParams;
        body: CreateCommentBody;
      };

    if (!(await userExists(body.authorId))) {
      response.status(400).json({
        error: {
          code: "INVALID_AUTHOR",
          message:
            "authorId does not reference an existing user.",
        },
      });
      return;
    }

    const comment = await createComment(
      params.ticketId,
      body.authorId,
      body.message,
    );

    response.status(201).json(comment);
  },
);

The route can safely use both the parent’s validated params and the child’s validated body.

Start with a valid collection request:

text

GET /api/tickets?status=open&priority=high&sortBy=createdAt&order=desc

GET /api/tickets?status=open&priority=high&sortBy=createdAt&order=desc

Then try an unsupported status:

text

GET /api/tickets?status=waiting

GET /api/tickets?status=waiting

The response should use HTTP 400 and include:

JSON

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request validation failed.",
    "details": [
      {
        "path": "status",
        "message": "Invalid option: expected one of \"open\"|\"in_progress\"|\"closed\""
      }
    ]
  }
}

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request validation failed.",
    "details": [
      {
        "path": "status",
        "message": "Invalid option: expected one of \"open\"|\"in_progress\"|\"closed\""
      }
    ]
  }
}

Try a malformed route parameter:

text

GET /api/tickets/not-a-ticket

GET /api/tickets/not-a-ticket

The request should fail before the repository lookup because it does not follow the tkt_<id> format.

Try an empty update:

text

PATCH /api/tickets/tkt_1001

PATCH /api/tickets/tkt_1001

JSON

{}

{}

The schema refinement should report that at least one field is required.

Finally, try an invalid nested comment:

text

POST /api/tickets/tkt_1001/comments

POST /api/tickets/tkt_1001/comments

JSON

{
  "authorId": "usr_agent_1",
  "message": "   "
}

{
  "authorId": "usr_agent_1",
  "message": "   "
}

The body should be rejected before PostgreSQL receives an insert request.

Zod answers questions such as:

Is requesterId a non-empty string?
Is priority one of the supported enum values?
Does ticketId follow the required format?
Is the update body non-empty?
Is the comment message within its length limit?

Repositories answer different questions:

Does the requester exist?
Does the author exist?
Does the ticket exist?
Can the row be inserted or updated under database constraints?

A body containing "requesterId": "usr_missing" is structurally valid. Zod accepts it, but userExists() rejects it with INVALID_REQUESTER.

Neither check establishes trusted identity. Authentication later replaces client-supplied requester and author IDs with identity derived from verified credentials.

You’ve replaced repeated route-local parsing with a reusable Zod validation boundary. Schemas now define the supported ticket ID format, normalized collection queries, creation defaults, partial-update rules, and nested comment input.

validateRequest() parses only the requested sections, stores normalized results in response.locals.validated, and preserves values created by earlier middleware. This makes it especially effective for nested routes where a parent validates parameters and a child later validates a body.

Thrown ZodError values flow into the centralized error handler, which produces consistent 400 VALIDATION_ERROR responses with readable field paths. Repositories remain focused on database work, while user and ticket existence checks continue to handle concerns that schemas cannot determine.