GET /posts always skips the first page of results

Nobody has started this yet — be first.

Business impact

Anyone browsing posts loses the newest content. GET /posts (and GET /posts/:id/comments) always renders newest-first, so "page 1" is supposed to be the freshest, most relevant page -- instead it silently skips exactly limit records before returning anything. On a blog with fewer posts than the page size, the homepage just renders empty. On a busier one, users land on page 1 and see content that's already one page stale. This is the kind of bug that looks like "the site is broken" to a reader and generates support/bug reports with no obvious cause, since nothing errors -- it just quietly returns the wrong slice.

Problem

toSkipTake(page, limit) computes skip = page * limit. For page=1, that's skip = limit -- i.e. the first page skips the first limit records instead of starting at offset 0.

Current behavior

GET /posts?page=1&limit=N returns 0 posts (or an already-stale window) even though N or more posts exist, because the very first page is computed as if it were the second.

Expected behavior

page=1 must return records starting at offset 0 (the newest records, given the orderBy: { createdAt: 'desc' } on GET /posts) -- it must never skip the first record. Later pages, and the "no error on the last partial page" and "empty array past the last page" behaviors, should all still work exactly as they do today.

Steps to reproduce

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

"page=1 does not skip the first record" and several sibling tests fail:

expected 5 posts, got 0.

Or directly:

node -e "console.log(require('./src/lib/pagination').toSkipTake(1, 10))"

-> { skip: 10, take: 10 } (should be { skip: 0, take: 10 })

Why this matters

This is a one-line off-by-one in the page->offset translation, the kind of mistake that's easy to make when writing this formula from memory (page * limit "feels" right at a glance) and easy to miss in review because it still type-checks and still returns a page of results -- just never the right one for page=1, and consistently the wrong window for every other page too.

Suggested approach

Look at toSkipTake in src/lib/pagination.js. The file's own comment block states the contract explicitly ("page=1 must return records starting at offset 0"); work out what skip needs to be when page=1 under that contract, and generalize from there.

Acceptance criteria

GET /posts?page=1&limit=N returns the N newest posts (or fewer, if fewer than N exist), never an empty page when posts exist.
toSkipTake(1, limit) returns { skip: 0, take: limit }.
Consecutive pages still cover every record exactly once with no overlap or gap.
A page beyond the last page still returns an empty array, not an error.

Verification

node_modules/.bin/jest --config practice-tickets/jest.config.js practice-tickets/tests/ticket01_pagination_skip_off_by_one.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/pagination-skip-off-by-one

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/pagination-skip-off-by-one

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 .