Validating Task Data with a Shared Helper

Welcome: From “It Works” to “It’s Safe to Use”

Welcome back. In the previous lesson, you used Codex to design the Task core: a shared Task model, an in-memory tasks array, and a service layer that knows how to create, read, update, and delete tasks. Your API can now do real work—but so far it mostly assumes that incoming JSON is correct. In this lesson, you’ll upgrade your Task Manager API from “accept anything and hope” to “trust but verify.” You’ll: Build a central task payload validator in src/lib/validateTaskPayload.ts Plug that validator into updateTaskById in src/lib/services/taskService.ts Wire validation into PUT and PATCH for src/app/api/tasks/[id]/route.ts, returning proper HTTP status codes You’ll continue to rely on Codex for implementation, but now your prompts will describe more nuanced rules: allowed fields, required fields, strict types, and how to propagate errors back to the client.

What We’re Building and Why It Matters

So far, your API can: Store tasks in memory Expose /api/tasks and /api/tasks/[id] routes Perform basic CRUD via the service layer What it does not do yet is enforce the rules of your domain. Examples: A client could send "completed": "yes" instead of a boolean. A task update could include random fields like "hack": "oops" . A PUT could omit required fields entirely. Without validation, bad data sneaks into your in-memory store and everything built on top becomes fragile. This lesson introduces a clear separation of concerns: validateTaskPayload checks if incoming data is shaped correctly. taskService.updateTaskById decides whether to mutate state based on validator results. The /api/tasks/[id] route translates service results into HTTP responses: 200, 400, 404, 204 . Once this pipeline is in place, every future feature you add (logging, persistence, UI) can assume the data is clean.

How We’ll Use Codex in This Lesson

You’ll use Codex in three focused ways: To implement the reusable validator One file: src/lib/validateTaskPayload.ts Well-defined function: validateTaskPayload(payload: any, partial = false): string[] Return array of human-readable error messages To integrate validation into the service layer One function: updateTaskById in src/lib/services/taskService.ts Call validateTaskPayload and decide whether to update or return an error object To enforce validation in PUT/PATCH routes File: src/app/api/tasks/[id]/route.ts Handlers use updateTaskById and map { error } / { task } to HTTP status codes Across all three, your prompts should: Restrict Codex to one file at a time Describe allowed fields, required fields, and type expectations clearly Explain how to treat partial updates vs full replacements Ask Codex to show the full updated file content

Join the 1M+ learners on CodeSignal

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

Step 1: Building a Shared Task Payload Validator

Your first job is to give the backend a single place that knows what a valid task payload looks like. The starter file already tells Codex what to do, but you’ll turn that into a concrete implementation:

TypeScript

// src/lib/validateTaskPayload.ts

// TODO: Ask Codex to implement a reusable validator for task payloads.
//
// Guidance example:
// "Codex, modify only src/lib/validateTaskPayload.ts. Implement
// validateTaskPayload(payload, partial=false) that returns an array of
// error messages for invalid fields, types, or missing required fields."

export function validateTaskPayload(
  payload: any,
  partial = false
): string[] {
  // TODO: Implement all validation rules here and return an array of errors.
  return ['TODO: implement validateTaskPayload'];
}

// src/lib/validateTaskPayload.ts

// TODO: Ask Codex to implement a reusable validator for task payloads.
//
// Guidance example:
// "Codex, modify only src/lib/validateTaskPayload.ts. Implement
// validateTaskPayload(payload, partial=false) that returns an array of
// error messages for invalid fields, types, or missing required fields."

export function validateTaskPayload(
  payload: any,
  partial = false
): string[] {
  // TODO: Implement all validation rules here and return an array of errors.
  return ['TODO: implement validateTaskPayload'];
}

Conceptually, validateTaskPayload should:

Ensure the payload is a non-null object (no arrays, no primitives)
Allow only title, content, completed, and dueDate
When partial is false (full update), require title, content, and completed
Enforce types:
- title / content → strings
- completed → boolean
- dueDate → string, valid date format if present

When everything is okay, it returns an empty array. When something is wrong, it returns a list of messages like:

text

[
  "Invalid request body. Expected a JSON object.",
  "Unexpected field: 'extra' is not allowed.",
  "Field 'completed' must be a boolean."
]

[
  "Invalid request body. Expected a JSON object.",
  "Unexpected field: 'extra' is not allowed.",
  "Field 'completed' must be a boolean."
]

A high-quality Codex prompt might look like:

Codex, modify only src/lib/validateTaskPayload.ts.

Implement validateTaskPayload(payload: any, partial = false): string[] that:

Returns an array of human-readable error messages.

Ensures payload is a non-null object (no arrays); otherwise return ['Invalid request body. Expected a JSON object.'].

Allows only title, content, completed, and dueDate; any other field should produce an error like Unexpected field: 'foo' is not allowed.

When partial is false, require title, content, and completed.

Validate types for each present field and check that dueDate is either a valid date string or undefined.

Return an empty array when the payload is valid.

Do not modify any other files. Show the full updated contents of src/lib/validateTaskPayload.ts.

TypeScript

// src/lib/services/taskService.ts
import { tasks, type Task } from '@/lib/tasks';
import { validateTaskPayload } from '@/lib/validateTaskPayload';

export const updateTaskById = (
  id: number,
  data: any,
  partial = true
): { task?: Task; error?: string } => {
  const index = tasks.findIndex(t => t.id === id);
  if (index === -1) return { error: 'Task not found' };

  // TODO: Ask Codex to validate `data` using validateTaskPayload before
  // applying any updates. If errors are returned, combine them into a
  // single string and return { error: combined } without mutating tasks.
  //
  // When valid:
  // - If partial is true, merge only provided fields into tasks[index].
  // - If partial is false, treat data as a full replacement for title,
  //   content, completed, and dueDate.

  return { task: tasks[index] };
};

// src/lib/services/taskService.ts
import { tasks, type Task } from '@/lib/tasks';
import { validateTaskPayload } from '@/lib/validateTaskPayload';

export const updateTaskById = (
  id: number,
  data: any,
  partial = true
): { task?: Task; error?: string } => {
  const index = tasks.findIndex(t => t.id === id);
  if (index === -1) return { error: 'Task not found' };

  // TODO: Ask Codex to validate `data` using validateTaskPayload before
  // applying any updates. If errors are returned, combine them into a
  // single string and return { error: combined } without mutating tasks.
  //
  // When valid:
  // - If partial is true, merge only provided fields into tasks[index].
  // - If partial is false, treat data as a full replacement for title,
  //   content, completed, and dueDate.

  return { task: tasks[index] };
};

Step 2: Validating Updates in the Service Layer

With the validator in place, you’ll make sure the service layer refuses invalid updates before they touch the in-memory tasks array.

The starter updateTaskById already hints at what should happen (as shown in src/lib/services/taskService.ts).

The core behavior you want is:

Find the task by id.
If not found, return { error: 'Task not found' }.
Validate the incoming data with validateTaskPayload(data, partial).
If there are errors, join them into a single string (e.g. errors.join('; ')) and return { error: combined }.
Do not mutate the task when validation fails.
Apply the update only when validation passes:
- For partial updates (partial = true): merge only the provided fields.
- For full updates (partial = false): treat the payload as a replacement for title, content, completed, and dueDate.
Return the updated task as { task: updatedTask }.

Your Codex prompt should capture that entire flow:

Codex, modify only src/lib/services/taskService.ts.

In updateTaskById, use validateTaskPayload(data, partial) to validate the incoming update before mutating tasks. If validateTaskPayload returns any errors, join them with '; ' and return { error: joinedErrors } without changing the array.

If there are no errors:

When partial is true, merge the provided fields into tasks[index].

When partial is false, treat data as a full replacement for title, content, completed, and dueDate, keeping the existing id.

Return { task: updatedTask } when successful.

Keep the existing function signature and do not modify any other functions or files. Show the full updated contents of src/lib/services/taskService.ts.

This keeps all validation logic in one place and all update behavior in another, while still letting them talk to each other.

TypeScript

// src/app/api/tasks/[id]/route.ts
// TODO: Ask Codex to implement GET, PUT, PATCH, and DELETE for /api/tasks/[id].
//
// Guidance example:
// "Codex, modify only src/app/api/tasks/[id]/route.ts. Use the taskService
// helpers to implement item-level CRUD, translating service errors to 404/400
// and returning appropriate JSON responses."

import { NextRequest, NextResponse } from 'next/server';
import { getTaskById, updateTaskById, deleteTaskById } from '@/lib/services/taskService';

type RouteContext = {
  params: {
    id: string;
  };
};

export async function GET(request: NextRequest, context: RouteContext) {
  // TODO: Parse the id, use getTaskById, and return 200/404 accordingly.
  return NextResponse.json({ error: 'TODO: implement GET /api/tasks/[id]' }, { status: 501 });
}

export async function PUT(request: NextRequest, context: RouteContext) {
  // TODO: Parse the id and JSON body, call updateTaskById with partial=false,
  // and return 200 on success, 404 if Task not found, or 400 for validation errors.
  return NextResponse.json({ error: 'TODO: implement PUT /api/tasks/[id]' }, { status: 501 });
}

export async function PATCH(request: NextRequest, context: RouteContext) {
  // TODO: Similar to PUT, but call updateTaskById with partial=true.
  return NextResponse.json({ error: 'TODO: implement PATCH /api/tasks/[id]' }, { status: 501 });
}

export async function DELETE(request: NextRequest, context: RouteContext) {
  // TODO: Parse the id, call deleteTaskById, and return 204 on success or 404 otherwise.
  return NextResponse.json({ error: 'TODO: implement DELETE /api/tasks/[id]' }, { status: 501 });
}

// src/app/api/tasks/[id]/route.ts
// TODO: Ask Codex to implement GET, PUT, PATCH, and DELETE for /api/tasks/[id].
//
// Guidance example:
// "Codex, modify only src/app/api/tasks/[id]/route.ts. Use the taskService
// helpers to implement item-level CRUD, translating service errors to 404/400
// and returning appropriate JSON responses."

import { NextRequest, NextResponse } from 'next/server';
import { getTaskById, updateTaskById, deleteTaskById } from '@/lib/services/taskService';

type RouteContext = {
  params: {
    id: string;
  };
};

export async function GET(request: NextRequest, context: RouteContext) {
  // TODO: Parse the id, use getTaskById, and return 200/404 accordingly.
  return NextResponse.json({ error: 'TODO: implement GET /api/tasks/[id]' }, { status: 501 });
}

export async function PUT(request: NextRequest, context: RouteContext) {
  // TODO: Parse the id and JSON body, call updateTaskById with partial=false,
  // and return 200 on success, 404 if Task not found, or 400 for validation errors.
  return NextResponse.json({ error: 'TODO: implement PUT /api/tasks/[id]' }, { status: 501 });
}

export async function PATCH(request: NextRequest, context: RouteContext) {
  // TODO: Similar to PUT, but call updateTaskById with partial=true.
  return NextResponse.json({ error: 'TODO: implement PATCH /api/tasks/[id]' }, { status: 501 });
}

export async function DELETE(request: NextRequest, context: RouteContext) {
  // TODO: Parse the id, call deleteTaskById, and return 204 on success or 404 otherwise.
  return NextResponse.json({ error: 'TODO: implement DELETE /api/tasks/[id]' }, { status: 501 });
}

Welcome: From “It Works” to “It’s Safe to Use”

What We’re Building and Why It Matters

How We’ll Use Codex in This Lesson

Join the 1M+ learners on CodeSignal

Step 1: Building a Shared Task Payload Validator

Step 2: Validating Updates in the Service Layer

Step 3: Enforcing Validation in PUT/PATCH /api/tasks/[id]

Summary and What’s Next