Reconcile reports false drift for any SKU that's ever had a release

Nobody has started this yet — be first.

Business impact

This project's reconciliation tooling exists specifically so that "does the materialized inventory match the ledger?" is something you can trust, not something you have to re-derive by hand during an incident. If Reconcile cries wolf on perfectly healthy SKUs -- reporting drift where there is none -- the team will do exactly what everyone does with noisy alerts: start ignoring them. The one time Reconcile reports a real drift, on-call may not take it seriously, because "oh, that report is always a little off."

Problem

Reconcile reports in_sync: false for a SKU that has only ever been restocked, reserved, and had a reservation manually released -- a perfectly healthy sequence with no bugs involved. The available figure it computes from the ledger is lower than the real, correct value by exactly however many units have ever been released.

Current behavior

Reconcile's Available formula is restock - reserve + expire, missing the + release term entirely, so every released unit is permanently uncounted in the "correct" figure it compares against.

Expected behavior

A SKU whose materialized sku_inventory row genuinely matches its ledger history should report in_sync: true, regardless of whether that history includes releases.

Steps to reproduce

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

Why this matters

Reconcile recomputes available from the ledger as restock - reserve + release + expire -- a release, like an expiry, gives its units back to available. The + release term is missing, so every released unit is permanently uncounted in the "correct" figure Reconcile compares against, even though the materialized row (which a release does update correctly) is fine.

Suggested approach

Look at the comment on LedgerReason in pkg/inventory/inventory.go, which documents the reason to account mapping every ledger row follows (release -> reserved -= delta, available += delta), and compare it against the Available formula inside Reconcile.

Acceptance criteria

Reconcile reports in_sync: true for a SKU whose history includes a restock, a reservation, and a release, with nothing else touching it
Reconcile still correctly reports drift when the materialized row is deliberately corrupted (don't just always report in-sync)
tickets/tests/ticket09_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket09 -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/reconcile-drops-release-term

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/reconcile-drops-release-term

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 .