Sweeper records "fired" and "invalidated" backwards

Nobody has started this yet — be first.

Business impact

The payment_timeouts.status column is the audit trail an on-call engineer or a support ticket investigation reaches for to answer "did this payment's timeout actually go off, or did it correctly get skipped because the payment had already moved on?" If that column is backwards, every such investigation gets the exact opposite answer -- "invalidated" when it really fired, "fired" when it was really a stale no-op. It won't break anything functionally, but it will actively mislead anyone who trusts this table, which is worse than having no record at all.

Problem

A timeout that genuinely fires (the payment really did transition) gets its payment_timeouts row marked status = 'invalidated'. A stale timeout that's correctly skipped gets marked status = 'fired'.

Current behavior

payment_timeouts.status reads "invalidated" for a timeout that actually fired, and "fired" for one that was correctly skipped as stale.

Expected behavior

Fired timeouts should be marked 'fired'; correctly-skipped stale ones should be marked 'invalidated' -- matching what the column name and every comment around it already say.

Steps to reproduce

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket11 -v

Why this matters

fireOne calls service.ApplyTimeoutEvent, gets back a fired bool, and then picks a finalStatus string based on it before writing it to payment_timeouts.status. The if/else branches choosing that string are swapped relative to the fired value.

Suggested approach

Look at the if fired { ... } else { ... } block in fireOne right after the call to service.ApplyTimeoutEvent, and check which string literal ("fired" vs "invalidated") each branch assigns against what fired actually means in each branch.

Acceptance criteria

A timeout that actually fires ends with payment_timeouts.status = 'fired'.
A stale timeout that's correctly skipped ends with payment_timeouts.status = 'invalidated'.
The paystate_timeouts_invalidated_total metric increments only for genuinely-invalidated (stale) timeouts, not fired ones.
tickets/tests/ticket11_test.go passes.
The project's own internal/timeout test suite still passes.

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket11 -v && TEST_DATABASE_URL=postgresql://... go test ./internal/timeout/... -race -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/sweeper-status-inverted

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/sweeper-status-inverted

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.