TIMEOUT_SWEEP_BATCH_SIZE is silently ignored

Nobody has started this yet — be first.

Business impact

An operator tuning the timeout sweeper's batch size under load (e.g. raising it because timeouts are backing up) sets TIMEOUT_SWEEP_BATCH_SIZE in their deployment config and sees... no change at all, because Load() is reading a differently-spelled env var name and always falls back to the default of 20. There's no error, no warning -- the setting is just 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.TimeoutSweepBatchSize, so setting the documented TIMEOUT_SWEEP_BATCH_SIZE has no effect.

Current behavior

Setting TIMEOUT_SWEEP_BATCH_SIZE=777 in the environment and calling config.Load() still returns TimeoutSweepBatchSize=20, the default.

Expected behavior

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

Steps to reproduce

os.Setenv("DATABASE_URL", "postgresql://x/x") os.Setenv("TIMEOUT_SWEEP_BATCH_SIZE", "777") cfg, _ := config.Load() fmt.Println(cfg.TimeoutSweepBatchSize) // prints 20, not 777

Why this matters

Load() builds Config field-by-field via getEnvInt(name, default) calls, one per env var. Every other field's getEnvInt/getEnvDuration 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 TimeoutSweepBatchSize against .env.example's TIMEOUT_SWEEP_BATCH_SIZE line, letter by letter.

Acceptance criteria

Setting TIMEOUT_SWEEP_BATCH_SIZE actually changes Config.TimeoutSweepBatchSize.
Leaving it unset still falls back to 20.
tickets/tests/ticket05_test.go passes.

Verification

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/config-env-var-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/config-env-var-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

Paystate — Declarative Payment State Machine

A production-grade declarative state-machine engine, demonstrated by a realistic payment lifecycle -- durable per-state timeouts and crash-recovery via a transactional outbox are the central engineering problems, not an afterthought.

Fork on GitHub

Download

Setup

Paystate — Declarative Payment State Machine

git clone <your-fork>
cd GolangDevTraining/paystate
docker compose up --build   # postgres + 2 app replicas + adminer

's build context is the repository root (one level above ), not itself -- has a local , reusing that sibling project's jittered-backoff package directly. Run from inside as usual; Compose resolves relative to the compose file regardless of your shell's working directory. shortens / to 10s/20s so the auto-expiry demo finishes fast.