Loading challenges
Nobody has started this yet — be first.
Business impact
Nothing stops the same order_reference from getting two independent, active reservations against the same SKU. A double-submitted "Buy Now" click -- a slow network causing a browser or client to fire the same request twice, a retried request from a flaky mobile connection -- today silently creates two separate holds for what should be one order, claiming twice the stock a single order actually needs.
Problem
checkDuplicateOrderReference exists only as a panicking TODO(ticket-22) stub; there is no way to reject a Reserve call whose order_reference already has an active reservation.
Current behavior
A second Reserve call reusing an order_reference that already has an active reservation currently panics with "TODO(ticket-22): checkDuplicateOrderReference not implemented".
Expected behavior
Service.SetDedupOrderReferences(true) opts a Service into rejecting a Reserve call whose order_reference already has an active reservation against the same SKU, with a new ErrDuplicateOrderReference. This is opt-in (default off) so existing callers that reuse order references for unrelated reasons aren't affected unless they explicitly turn it on.
Steps to reproduce
go test ./tickets/tests/... -run TestTicket22 -vWhy this matters
The check needs to run inside the same transaction as the claim itself (so there's no window between "check for a duplicate" and "claim stock" where a second concurrent request could sneak through), and it must only ever look at active reservations -- a customer legitimately re-ordering the same product after their first order already shipped (committed) or was cancelled (released) must not be blocked forever by their own order history.
Suggested approach
Look at checkDuplicateOrderReference's stub and its call site in Reserve (guarded by s.dedupOrderReferences && orderReference != "", so it never affects a Service that hasn't opted in). It runs inside the same transaction tx the claim itself uses -- a SELECT ... FROM reservations WHERE sku_id = $1 AND order_reference = $2 AND status = 'active' is enough to answer "does an active reservation with this reference already exist?".
Acceptance criteria
Verification
TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket22 -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
Sign in to create it automatically, or do it yourself:
$git checkout -b feat/duplicate-order-reference-guardFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/duplicate-order-reference-guardSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign inSKIP LOCKEDhttp://localhost:8081localhost:5434flash-saleeveryday-widgetcurl localhost:8081/healthzgo run ./cmd/loadtest -url http://localhost:8081 -sku flash-sale -concurrency 10000Work the tickets in tickets/docs/ (ordered easy → hard); each names one dedicated Go test in tickets/tests/:
export TEST_DATABASE_URL=postgresql://inventory:inventory@localhost:5432/inventory_test?sslmode=disable
go test ./tickets/tests/... -run TestTicket24 -v # a single ticket
./tickets/run_tickets.sh # all 25, clean pass/fail summary
Tickets that don't touch Postgres (02, 07, 17, 19) run fine without TEST_DATABASE_URL; the rest t.Skip cleanly, not fail, if it's unset.
Level 2
Implement a feature
Extend the system within its own patterns.