Re-committing an already-committed reservation now fails

Nobody has started this yet — be first.

Business impact

This project's README explicitly documents idempotent commit as a guarantee: "committing an already-committed reservation must return the same result without incrementing sold again, because a retried payment webhook calling this twice is a completely normal occurrence." With this bug, the second call from a retried webhook now gets an error instead of the expected success -- depending on how the caller handles that error, this can mean re-attempting a charge that already went through, or reporting a successful payment as failed to the customer.

Problem

Calling Commit a second time on a reservation that's already committed returns ErrReservationNotActive instead of succeeding with the same result as the first call.

Current behavior

resolve's terminal-state check (status != active) runs before its idempotent no-op check, so it rejects every re-commit before the code ever reaches the check that was supposed to let it through.

Expected behavior

A second Commit call on an already-committed reservation should succeed, returning the same reservation (still status: committed), without changing sold again. The same applies to Release on an already-released reservation.

Steps to reproduce

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

Why this matters

resolve is supposed to check "is this the idempotent no-op case?" before checking "is this reservation in some other terminal state?". Those two checks have been swapped: the terminal-state check (status != active) now runs first, and it's true for any already-committed reservation (including the one this exact call is trying to no-op against) -- so it rejects the retry before the code ever reaches the idempotency check that was supposed to let it through.

Suggested approach

Look at the order of the if statements at the top of resolve in pkg/inventory/service.go: the "already committed" / "already released" no-op checks, and the "not active" rejection. One of these needs to run before the other.

Acceptance criteria

Calling Commit twice on the same reservation succeeds both times, with the same status: committed result
Calling Release twice on the same reservation succeeds both times, with the same status: released result
Committing an already-released reservation (a genuinely invalid transition, not the idempotent case) still correctly fails with ErrReservationNotActive
tickets/tests/ticket15_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket15 -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/idempotency-check-order

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/idempotency-check-order

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 .