Reservation API responses swap created_at and expires_at

Nobody has started this yet — be first.

Business impact

Any client showing a countdown ("your hold expires in 4:58") or checking whether a reservation is about to lapse computes expires_at - created_at (or just compares expires_at to "now") and gets a negative number or an already-past timestamp for a reservation that was just created and is nowhere close to expiring. A checkout page built on this API would show "this item's hold expired 4 minutes ago" the instant a customer adds it to their cart.

Problem

Every reservation the API returns (from POST /v1/skus/{id}/reservations, GET /v1/reservations/{id}, commit, and release) reports expires_at that is before created_at.

Current behavior

toReservationResponse assigns ExpiresAt: r.CreatedAt and CreatedAt: r.ExpiresAt -- the two fields are swapped in the struct literal.

Expected behavior

expires_at must always be after created_at for a freshly created reservation (that's the entire point of a time-to-live hold).

Steps to reproduce

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

Why this matters

toReservationResponse builds the JSON response struct by copying fields off the domain Reservation value. Two of those field assignments got swapped -- a classic copy-paste/reordering mistake when a struct literal has many same-typed fields sitting next to each other.

Suggested approach

Compare toReservationResponse in internal/handler/dto.go field by field against the reservationResponse struct's own field names right above it. ExpiresAt should come from the domain value's ExpiresAt.

Acceptance criteria

A freshly created reservation's JSON response has expires_at after created_at
expires_at reflects the actual configured TTL from created_at (e.g. ~5 minutes later by default)
tickets/tests/ticket05_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket05 -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/reservation-response-timestamp-swap

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/reservation-response-timestamp-swap

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 .