The demo SKUs are never seeded on a fresh database

Nobody has started this yet — be first.

Business impact

The README's entire quickstart -- docker compose up --build, then run the load test against the flash-sale SKU -- depends on this seeding step actually creating that SKU. With this bug, a brand new deployment starts up successfully (no errors, no crash) but the demo SKUs simply do not exist: the load-test tool's default target immediately 404s, and anyone following the README's own instructions hits a wall on their very first command with no indication of why.

Problem

seed.Run completes without error on a fresh database, but neither the flash-sale nor everyday-widget SKU actually gets created.

Current behavior

Run's "already seeded?" check skips seeding whenever GetSKU returns an error -- but GetSKU returns ErrSKUNotFound precisely when the SKU does not exist yet, which is exactly the case that should trigger seeding.

Expected behavior

On a fresh database, seed.Run creates both demo SKUs with their documented stock levels. On an already-seeded database (e.g. a second replica starting up, or a restart), it is a safe no-op -- it must not double-restock a SKU that already exists.

Steps to reproduce

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

Why this matters

Run's "already seeded?" check is inverted: it skips seeding whenever GetSKU returns an error -- but GetSKU returns ErrSKUNotFound precisely when the SKU does not exist yet, which is exactly the case that should trigger seeding, not skip it. On a fresh database, every demo SKU look-up returns that not-found error, so every seed attempt is skipped.

Suggested approach

Read the comment right next to the continue in seed.Run's loop -- it says "already seeded" -- and check whether the condition above it actually means "already seeded" or the opposite.

Acceptance criteria

On a fresh database, seed.Run creates both demo SKUs with the correct stock levels (seed.FlashSaleStock, seed.NormalStock)
Calling seed.Run a second time against an already-seeded database does not change either SKU's total (no double-restock)
tickets/tests/ticket11_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket11 -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/seed-inverted-condition

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/seed-inverted-condition

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 .