The reaper can claim the same due reservation twice under concurrency

Nobody has started this yet — be first.

Business impact

This is the exact "many replicas must not double-release the same due work" guarantee the README calls out as this project's reason for running two app replicas by default. Without it, two reaper replicas polling at the same moment can both claim and release the SAME expired reservation -- crediting its quantity back to available twice. In a real flash sale that means phantom stock appearing out of nowhere, which can then be sold to a second buyer for a unit that was never actually free.

Problem

SelectDueReservations's query is missing FOR UPDATE SKIP LOCKED. A second, concurrently-open transaction's identical due-work query can return the same row(s) a first transaction has already selected, even though the first hasn't committed or written anything yet.

Current behavior

A second, concurrently-open transaction's SelectDueReservations call returns the same reservation a first transaction already claimed and has not yet committed or rolled back.

Expected behavior

A row already selected (and about to be claimed) by one transaction should not be selectable by a second, concurrently-open transaction running the same query -- FOR UPDATE SKIP LOCKED is what provides that.

Steps to reproduce

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

Why this matters

A genuinely concurrent, goroutine-based version of this test turns out to be too timing-dependent to reliably trigger in practice. This ticket's test instead drives the exact production function, SelectDueReservations (exported specifically for this reason, and the same function ReapOnce itself calls), from two manually-sequenced transactions, deterministically -- SKIP LOCKED never blocks, so two sequential calls in one goroutine, with the first transaction deliberately left open, are enough to prove the claim is (or isn't) exclusive, with zero timing luck involved.

Suggested approach

Compare SelectDueReservations's SELECT against LockReservation's SELECT in pkg/inventory/service.go (right below it in the file listing) for the general shape of a claiming query, and check git log/the migration file's comment on reservations_due_idx for what the intended claiming pattern was.

Acceptance criteria

SelectDueReservations uses FOR UPDATE SKIP LOCKED
Two manually-sequenced transactions calling SelectDueReservations concurrently never return the same row to both
pkg/inventory's existing reaper tests still pass
tickets/tests/ticket24_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket24 -v -count=5

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/reaper-missing-skip-locked

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/reaper-missing-skip-locked

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 .