REAPER_BATCH_SIZE is silently ignored

Nobody has started this yet — be first.

Business impact

An operator tuning the TTL reaper under load (e.g. raising the batch size because expired reservations are piling up faster than the reaper clears them) sets REAPER_BATCH_SIZE in their deployment config and sees no change at all. There is no error, no warning -- the setting is silently discarded. This is exactly the kind of bug that costs an on-call engineer an hour of "I set it, why isn't it working?!" before anyone thinks to grep the source for the literal env var name.

Problem

config.Load() reads a misspelled environment variable name for Config.ReaperBatchSize, so setting the documented REAPER_BATCH_SIZE has no effect.

Current behavior

Setting REAPER_BATCH_SIZE=777 and calling config.Load() still returns ReaperBatchSize == 100 (the default), because the getEnvInt call for that field reads a different string than the documented env var name.

Expected behavior

REAPER_BATCH_SIZE (as documented in .env.example and the README's configuration table) should actually control Config.ReaperBatchSize.

Steps to reproduce

go test ./tickets/tests/... -run TestTicket02 -v
Or: os.Setenv("DATABASE_URL", "postgresql://x/x"); os.Setenv("REAPER_BATCH_SIZE", "777")
cfg, _ := config.Load()
fmt.Println(cfg.ReaperBatchSize) -- prints 100, not 777.

Why this matters

Load() builds Config field-by-field via getEnvInt(name, default) calls, one per env var. Every other field's call uses the exact documented name -- this one field's call has a typo in the string literal passed as name.

Suggested approach

Compare the string literal passed to getEnvInt for ReaperBatchSize against .env.example's REAPER_BATCH_SIZE line, letter by letter.

Acceptance criteria

Setting REAPER_BATCH_SIZE actually changes Config.ReaperBatchSize
Leaving it unset still falls back to 100
tickets/tests/ticket02_test.go passes

Verification

go test ./tickets/tests/... -run TestTicket02 -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/reaper-batch-size-typo

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-batch-size-typo

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 .