Outbox payload key typo silently breaks every non-default demo profile

Nobody has started this yet — be first.

Business impact

This is a "someone renamed a field on one side and missed a call site" bug -- a classic real production incident shape, especially across a producer/consumer boundary like this one (a JSON payload written by one component, read by another). The visible symptom is severe and confusing: every payment, no matter what simulator_profile was requested at creation, silently gets approved by the demo bank simulator. The "silent" auto-expiry demo and the "decline" demo both stop working project-wide -- not because those features are broken, but because the profile that selects them never reaches the simulator at all.

Problem

A payment created with simulator_profile: "silent" (or "decline") gets authorized anyway, as if it had been created with "approve" (the default).

Current behavior

Every payment ends up authorized regardless of the requested simulator_profile.

Expected behavior

The requested simulator_profile should reach the bank simulator's Initiate call unchanged, and drive the outcome its switch statement (in internal/bank/simulator.go) actually implements for that profile.

Steps to reproduce

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

Why this matters

Service.Create inserts an outbox row of kind upi_initiate with a JSON payload map. internal/outbox/dispatcher.go's callBank later reads that payload back (payload["simulator_profile"]) to build the HTTP request it sends to the bank simulator. The two sides need to agree on the exact key string -- right now they don't.

Suggested approach

Look at the map literal Service.Create passes to s.store.InsertOutbox(...) for the upi_initiate kind, and compare every key against what internal/outbox/dispatcher.go's callBank actually reads out of payload[...]. One of them has a typo.

Acceptance criteria

A payment created with simulator_profile: "silent" is dispatched to the bank simulator WITH that profile, and does not get auto-authorized.
A payment created with simulator_profile: "decline" ends up failed, not authorized.
The default ("approve") profile still authorizes as before.
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/simulator-profile-payload-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/simulator-profile-payload-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.