Builder.Timeout accepts a zero-duration timeout

Nobody has started this yet — be first.

Business impact

This is in the reusable state-machine library, so it affects every future caller, not just payments. A zero-duration Timeout schedules a deadline of "right now" -- the sweeper could claim and fire it before the very transaction that created it has even returned a response to the caller. For a payment machine specifically, imagine someone later adds Timeout("some_state", cfg.SomeDuration, "give_up") and SomeDuration comes from a misconfigured env var that parses to 0 -- instead of a clear startup error ("duration must be positive"), the app starts fine and then behaves nondeterministically in production, which is a much more expensive class of bug to diagnose.

Problem

Builder.Timeout(state, 0, event) is silently accepted by Build() instead of being rejected as invalid.

Current behavior

A zero-duration Timeout call, followed by Build(), returns a nil error -- but it should not.

Expected behavior

Build() should return an error for a zero-duration timeout, exactly the way it already does for a negative one.

Steps to reproduce

_, err := statemachine.New("widget"). State("a"). State("b", statemachine.Terminal()). Transition("a", "go", "b", nil, nil). Timeout("a", 0, "go"). Build() // err is nil -- but it shouldn't be

Why this matters

Look at the validation in Builder.Timeout: it already has a branch that rejects an invalid duration and produces a *BuildError naming the state and the bad duration. The bug is purely in which durations that branch considers invalid.

Suggested approach

Compare the current condition against the error message right next to it -- it says "must be positive." Is 0 positive?

Acceptance criteria

Timeout("x", 0, event) causes Build() to return a non-nil error.
Timeout("x", -time.Second, event) still causes Build() to return a non-nil error (don't regress the existing negative case).
Timeout("x", time.Second, event) still builds successfully.
tickets/tests/ticket02_test.go passes.
The existing pkg/statemachine test suite (TestBuild_TimeoutOnUndeclaredState_IsError and friends) still 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/zero-duration-timeout-accepted

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/zero-duration-timeout-accepted

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.