GET .../ledger?limit=500 rejects its own documented maximum

Nobody has started this yet — be first.

Business impact

Any dashboard, audit tool, or support script that paginates the append-only ledger using the documented maximum page size of 500 gets a 400 Bad Request instead of a page of results -- for the exact value the API's own error message claims is valid. It is a small thing, but it is the kind of small thing that erodes trust in an API's documentation: if the boundary value in the error message is wrong, what else is?

Problem

GET /v1/skus/{id}/ledger?limit=500 returns 400 Bad Request with body {"error":"limit must be between 1 and 500"}.

Current behavior

ListLedger's validation checks n <= 0 || n >= 500, rejecting the one value (500) its own error message documents as the valid maximum.

Expected behavior

A limit of exactly 500 should be accepted and return up to 500 ledger entries, matching what the error message itself documents as the valid range.

Steps to reproduce

go test ./tickets/tests/... -run TestTicket03 -v

Why this matters

ListLedger's query-param validation checks a boundary condition on a value that's about to be used as a LIMIT in a SQL query. A stray = on the wrong side of that check rejects the one value it's supposed to allow.

Suggested approach

Look at the boundary check on the parsed limit value in ListLedger and compare it to the error message string sitting right next to it.

Acceptance criteria

limit=500 returns 200 OK
limit=501 still correctly returns 400 (don't just remove the upper bound)
limit=0 and limit=-1 still correctly return 400
tickets/tests/ticket03_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket03 -v

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/ledger-limit-boundary

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/ledger-limit-boundary

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

Inventory Reservation Service

Oversell-proof stock reservations under extreme concurrent contention: 100 units, 50,000 simultaneous "Buy Now" clicks, and exactly 100 must succeed.

Fork on GitHub

Download

Setup

Inventory Reservation Service

git clone <your-fork>
cd GolangDevTraining/inventory
docker compose up --build   # Postgres + 2 hot-reloading app replicas + Adminer

Two app replicas are on by default, not opt-in: the TTL reaper's claiming and the reservation hot path's atomicity guarantee only prove anything interesting with more than one process sharing the same Postgres and the same SKU row. App replica 1 is reachable at ; Postgres at . Seeded on startup: (10 units) and (5,000 units). Verify with and .