Restocking with quantity: 0 returns a raw database error

Nobody has started this yet — be first.

Business impact

A warehouse-integration script or admin tool that occasionally computes a restock delta of exactly zero (nothing changed since the last sync) -- a perfectly normal, meaningless no-op -- gets back a 500 Internal Server Error with a raw Postgres constraint-violation message instead of a clean rejection. Anyone integrating against this API has to specifically special-case "don't send zero" rather than trusting the API to handle it gracefully, and every occurrence pollutes error-rate monitoring with a 5xx that isn't actually a server problem.

Problem

POST /v1/skus with {"sku_id": "x", "quantity": 0} returns 500 Internal Server Error with a body like {"error":"restock: ledger: ERROR: new row for relation \"stock_ledger\" violates check constraint \"stock_ledger_delta_check\" (SQLSTATE 23514)"}.

Current behavior

Restock's guard checks qty < 0 instead of qty <= 0, so 0 slips past validation and reaches the database, where stock_ledger's own CHECK (delta > 0) constraint rejects the ledger insert.

Expected behavior

A quantity of 0 should be rejected the same clean way a negative quantity already is: a 400/422 with ErrInvalidQuantity's message, never reaching the database at all.

Steps to reproduce

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

Why this matters

Restock's doc comment describes it as "creates the SKU ... or adds qty" -- a quantity of zero is a meaningless restock and should be rejected up front, exactly like a negative one. Its guard checks qty < 0 instead of qty <= 0, so 0 slips past validation and reaches the database, surfacing as an opaque, unrelated-looking database error mapped to a bare 500.

Suggested approach

Look at the comparison operator in Restock's quantity guard in pkg/inventory/service.go, right next to ErrInvalidQuantity's own message ("quantity must be positive"). Zero is not positive.

Acceptance criteria

Restock (and POST /v1/skus) reject quantity: 0 with ErrInvalidQuantity (mapped to 400), not a 500
Restock still rejects negative quantities the same way
Restock with a positive quantity still works as before
tickets/tests/ticket04_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket04 -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/restock-zero-quantity-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/restock-zero-quantity-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 .