Restocking an existing SKU resets its version counter to 1

Nobody has started this yet — be first.

Business impact

sku_inventory.version exists so the optimistic-locking strategy (and any future tooling that reasons about "has this row changed since I last looked?") can detect concurrent writers. If a routine restock silently resets it back to 1, any external system caching "the version I last saw was N" now sees a version lower than one it already observed -- undermining the entire assumption that version only ever climbs. This kind of bug tends to stay invisible for a long time (nothing crashes) and then causes deeply confusing behavior in whatever eventually relies on version being monotonic.

Problem

Every restock of an already-existing SKU resets sku_inventory.version back to 1, instead of incrementing it.

Current behavior

Restock's INSERT ... ON CONFLICT DO UPDATE clause sets version = EXCLUDED.version, but EXCLUDED.version is always the literal 1 from the INSERT's own VALUES list.

Expected behavior

version should increase by exactly 1 on every write to the row -- restocks included, the same as reservations, commits, releases, and expiries already do.

Steps to reproduce

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

Why this matters

Restock's INSERT ... ON CONFLICT DO UPDATE clause sets version = EXCLUDED.version -- but EXCLUDED.version is always the literal 1 from the INSERT's own VALUES list (used only for the very first creation), not a computed "current version + 1". Every subsequent restock of the same row re-applies that same literal 1.

Suggested approach

Compare the version assignment in Restock's ON CONFLICT clause against how every other write to sku_inventory in this codebase increments version (grep -n "version = sku_inventory.version" pkg/inventory will find several).

Acceptance criteria

The first restock of a new SKU sets version = 1
Each subsequent restock of the same SKU increases version by exactly 1
tickets/tests/ticket10_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket10 -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-version-reset

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-version-reset

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 .