Add inventory.Repair (fix drift the reconciliation tool finds)

Nobody has started this yet — be first.

Business impact

Reconcile can detect drift between the materialized sku_inventory row and what the ledger says is true, but there is no way to fix it short of hand-writing SQL during an incident -- exactly the kind of manual, error-prone, hard-to-audit intervention this project's append-only ledger design is supposed to make unnecessary.

Problem

inventory.Repair does not exist yet; there is no automated way to correct drift Reconcile reports.

Current behavior

Calling inventory.Repair currently panics with "TODO(ticket-23): Repair not implemented".

Expected behavior

Repair(ctx, pool, skuID) (Drift, error) recomputes the correct values for a SKU (the same computation Reconcile already does) and writes them back to sku_inventory, so a subsequent Reconcile call reports in_sync: true. It returns the drift it found (and fixed).

Steps to reproduce

go test ./tickets/tests/... -run TestTicket23 -v
Observe: panics with "TODO(ticket-23): Repair not implemented".

Why this matters

The repair must be safe against a concurrent Reserve/Commit/Release happening at the same time -- locking the row for the duration of the read-recompute-write, the same way every other write to sku_inventory in this codebase already does, so a repair can't race a legitimate concurrent claim and either overwrite it or itself get overwritten by a stale write.

Suggested approach

Compare Reconcile's own two-part structure (read the materialized row, sum the ledger) against what Repair needs to do differently: instead of just comparing and returning, Repair needs to SELECT ... FOR UPDATE the row first (so nothing else can write to it mid-repair), do the same ledger-sum computation, and UPDATE sku_inventory to match before releasing the lock.

Acceptance criteria

Repair corrects a materialized row that has drifted from its ledger, so a subsequent Reconcile reports in_sync: true
Repair returns the drift it found (its own Drift.InSync should be false when it actually had something to fix)
A SKU with no drift is left unchanged by Repair
tickets/tests/ticket23_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket23 -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 feat/reconcile-repair

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin feat/reconcile-repair

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 .