The optimistic strategy retries the wrong errors

Nobody has started this yet — be first.

Business impact

This defeats the entire point of the optimistic locking strategy under the exact conditions it's supposed to handle: real contention. A genuine flash sale means many buyers racing to update the same SKU row -- version conflicts are the expected, normal, recoverable case the retry loop exists for. With this bug, a real conflict now fails immediately instead of retrying, so under real load LOCK_STRATEGY=optimistic would reject far more legitimate buyers than it should.

Problem

A version conflict (ErrVersionConflict) -- the one error the retry loop is specifically built to recover from -- is never retried; it fails on the very first collision, regardless of how many attempts are configured.

Current behavior

IsRetryableClaimError returns !errors.Is(err, ErrVersionConflict) -- the extra ! inverts the whole decision, so a real version conflict is classified as not retryable.

Expected behavior

ErrVersionConflict should be retried (up to MaxAttempts, with backoff). Every other error (insufficient stock, unknown SKU, a generic database fault) should fail immediately -- retrying those wastes the attempt budget on something that can never succeed by trying again.

Steps to reproduce

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

Why this matters

Claim's retry Policy.Classifier is supposed to be errors.Is(err, ErrVersionConflict). It has an extra !, inverting the whole decision. This ticket's test extracts the classifier into its own named function (IsRetryableClaimError, the exact function Claim's policy uses, not a copy of it) and tests it directly as a pure function -- no database, no concurrency, no interaction with ticket-12's separate arithmetic bug on the same code path.

Suggested approach

Look at IsRetryableClaimError in pkg/inventory/optimistic.go and compare it against its own doc comment directly above it.

Acceptance criteria

IsRetryableClaimError(ErrVersionConflict) returns true
IsRetryableClaimError returns false for ErrInsufficientStock, ErrSKUNotFound, and a generic error
pkg/inventory's existing optimistic-strategy tests pass (once ticket-12 is also fixed)
tickets/tests/ticket19_test.go passes

Verification

go test ./tickets/tests/... -run TestTicket19 -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-classifier-inverted

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-classifier-inverted

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 .