Optimistic claims add to available instead of subtracting

Nobody has started this yet — be first.

Business impact

This is a sign error in the exact statement responsible for one of this project's two core locking strategies. Left alone, every optimistic reservation would either corrupt the SKU's numbers or (thanks to a database safety net) fail outright with a confusing error -- either way, any deployment configured to use LOCK_STRATEGY=optimistic is completely broken for its one job: correctly tracking how much stock is left.

Problem

Reserve against a SKU using the optimistic strategy fails with a low-level, confusing Postgres error ("current transaction is aborted, commands ignored until end of transaction block") instead of succeeding.

Current behavior

OptimisticStrategy.Claim's UPDATE has available = available + $2 instead of available = available - $2, which breaks sku_inventory's CHECK (available + reserved + sold = total) constraint and aborts the whole transaction.

Expected behavior

Claiming stock should succeed normally: available decreases by the claimed quantity, reserved increases by the same amount.

Steps to reproduce

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

Why this matters

OptimisticStrategy.Claim's has instead of -- claiming stock is supposed to move units out of available, not add more. Because has a constraint, adding to while also adding to breaks that balance ( doesn't move), so Postgres itself rejects the -- the bug doesn't silently corrupt data, it hard-fails every claim attempt. That's a lucky consequence of the schema's own safety net, not something the code did on purpose; a schema without that constraint would have silently let stock counts run away in the wrong direction.

Suggested approach

Compare the sign on the available assignment in OptimisticStrategy.Claim's UPDATE against ConditionalStrategy.Claim's UPDATE in the sibling file pkg/inventory/conditional.go -- both strategies are claiming the same thing and should move available the same direction.

Acceptance criteria

Reserve using OptimisticStrategy succeeds normally for a valid quantity
available decreases and reserved increases by exactly the claimed quantity
pkg/inventory's existing optimistic-strategy tests pass
tickets/tests/ticket12_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket12 -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/optimistic-sign-flip

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/optimistic-sign-flip

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 .