Outbox rows get one extra retry beyond OUTBOX_MAX_ATTEMPTS

Nobody has started this yet — be first.

Business impact

OUTBOX_MAX_ATTEMPTS is the operator's explicit promise to a downstream integration partner (the bank/UPI rail) about how many times we'll retry a call before giving up and dead-lettering it for manual review. If the dispatcher silently allows one extra attempt beyond that, a downstream that's rate-limiting or already returning "permanently rejected" gets hit one more time than agreed -- small on its own, but it's exactly the kind of drift that breaks an SLA with a partner who's counting requests on their side.

Problem

With OUTBOX_MAX_ATTEMPTS=2, a row that fails on every call is only dead-lettered after its 3rd failed attempt, not its 2nd.

Current behavior

A row still shows status "pending" after exactly maxAttempts failed dispatch attempts, when it should already be "dead".

Expected behavior

A row should be dead-lettered exactly when attempts reaches maxAttempts -- no more.

Steps to reproduce

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

Why this matters

retryOrDeadLetter computes attempts := r.attempts + 1 (the count including this failure) and compares it against d.maxAttempts to decide dead-letter vs. reschedule. The comparison operator determines whether the last permitted attempt is treated as the final one or as one that still gets a follow-up retry.

Suggested approach

Walk through the arithmetic by hand for maxAttempts = 1: after the first (and only allowed) failure, attempts is 1. Should that dead-letter immediately, or get one more try first? Compare the current operator against that expectation.

Acceptance criteria

With maxAttempts = N, a row that fails every time is dead-lettered with attempts == N, not N+1.
A row that succeeds before exhausting attempts is still marked processed as before (don't break the happy path).
tickets/tests/ticket10_test.go passes.

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket10 -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/outbox-dead-letter-off-by-one

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/outbox-dead-letter-off-by-one

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.