Empty and whitespace-only comments are accepted

Nobody has started this yet — be first.

Business impact

Anyone can post a comment with no actual content -- an empty string, or a string of only spaces/tabs/newlines that renders as a blank line in any UI. On a public blog that's a moderation and trust problem: blank comments clutter every post's comment thread, make it harder for real readers to follow a discussion, and are exactly the shape of noise automated spam/abuse tools send first to probe whether validation exists at all.

Problem

createCommentSchema.content is declared as z.string().trim().min(0, 'Content must not be empty'). .trim() strips leading/trailing whitespace, but .min(0, ...) accepts a string of length zero -- so both "" and " " (which trims to "") pass validation and the comment is created.

Current behavior

POST /posts/:id/comments with content: "" or content: " " returns 201 Created and stores a blank comment, instead of the 400 VALIDATION_ERROR the schema's own error message claims it enforces.

Expected behavior

A comment whose content is empty, or entirely whitespace, is rejected with 400 VALIDATION_ERROR, matching the "must not be empty" message the schema already declares (and matching how createPostSchema.title / createPostSchema.content already enforce the same rule with .min(1, ...)).

Steps to reproduce

cd nodejs/blog_api npm test -- tests/comments.test.js

"rejects empty comment content" fails: expected 400, got 201.

Or directly, once a user/post exist:

curl -s -X POST http://localhost:3000/posts/1/comments
-H "Authorization: Bearer <token>" -H "Content-Type: application/json"
-d '{"content": " "}'

-> 201 Created (should be 400 VALIDATION_ERROR)

Why this matters

.min(0, ...) and .min(1, ...) are one character apart and both "look" like a length check at a glance -- a classic boundary-value slip, made worse here because the message string attached to the rule ('Content must not be empty') still reads as if the check works, so a quick read of the schema doesn't reveal the bug; you have to notice the argument is 0, not 1.

Suggested approach

Compare createCommentSchema.content in src/validation/schemas.js against createPostSchema.content a few lines above, which enforces the identical "non-empty after trim" rule correctly.

Acceptance criteria

POST /posts/:id/comments with content: "" returns 400 VALIDATION_ERROR.
POST /posts/:id/comments with content: " " (whitespace only) returns 400 VALIDATION_ERROR.
POST /posts/:id/comments with real, non-empty content still succeeds.

Verification

node_modules/.bin/jest --config practice-tickets/jest.config.js practice-tickets/tests/ticket02_empty_comment_content_accepted.test.js --verbose

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/empty-comment-content-accepted

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/empty-comment-content-accepted

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Blog API — Where Authentication Stops and Authorization Begins

A production-quality Node/Express/Prisma Blog API whose central engineering lesson is that authentication and authorization are two separate, sequentially-enforced checks -- a valid JWT proves who you are, a server-side ownership re-check proves what you're allowed to do to this specific resource.

Fork on GitHub

Download

Setup

Blog API — Where Authentication Stops and Authorization Begins

git clone <your-fork>
cd blog_api
docker compose up --build   # postgres + app; migrations run automatically before the server starts

The app listens on host port 3002 and Postgres on host port 5434 (chosen to avoid clashing with sibling projects that commonly use 8000/5432). Tear down (including the Postgres volume) with .