Nobody has started this yet — be first.
Business impact
pkg/statemachine.Machine already exposes State(name) (State, bool), which returns a full State struct (Name, Terminal, Failure) plus an ok bool. Any caller that only wants to know "is this state terminal?" has to call State, check ok, then check .Terminal -- three steps for a one-fact question. This is a small ergonomic gap in the reusable library itself.
Problem
There is no one-line way for a caller of pkg/statemachine to ask "is this state terminal?" -- they must call State, check ok, then check .Terminal, three steps for a one-fact question.
Current behavior
Calling the not-yet-implemented Machine.IsTerminal panics (a stub) instead of returning a bool.
Expected behavior
A one-line convenience: Machine.IsTerminal(name string) bool, returning false for an undeclared state (matching State's ok=false behavior) and otherwise the state's Terminal flag.
Steps to reproduce
m, _ := statemachine.New("x").State("a", statemachine.Terminal()).State("b").Build() m.IsTerminal("a") // should be true m.IsTerminal("b") // should be false m.IsTerminal("no-such") // should be false, not panic
Why this matters
This is a small ergonomic gap in the reusable library itself -- every future caller of pkg/statemachine (not just internal/payment) hits this same three-step dance if they ever want to decide something based on terminality (e.g. "should the caller bother persisting a new updated_at-adjacent audit trail entry, or scheduling a timeout, once a transition lands on a terminal state?").
Suggested approach
Look at how Machine.State already does the m.states[name] lookup and returns the zero value + false on a miss. IsTerminal needs the same lookup, just condensed to a single bool. You do not need to change State, stateDef, or any Builder code -- this is purely a new read-only method on Machine.
Acceptance criteria
Verification
go test ./tickets/tests/... -run TestTicket06 -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
Sign in to create it automatically, or do it yourself:
$git checkout -b feat/machine-isterminalFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/machine-isterminalSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign indocker composepaystate/paystate/go.modreplace reliable => ../reliabledocker compose up --buildpaystate/context: ..docker-compose.ymlCREATED_TIMEOUTAUTHORIZED_TIMEOUTWork the tickets in tickets/docs/ (ticket-01 through ticket-25); each names one Go test in tickets/tests/:
TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket01 -v # a single ticket
TEST_DATABASE_URL=postgresql://... ./tickets/run_tickets.sh # all 25, clean pass/fail summary
Tickets that don't touch Postgres (02, 03, 04, 05, 06, 14, 15, 24) run fine without TEST_DATABASE_URL set; the rest report FAIL with a "TEST_DATABASE_URL not set" message if it's missing. make test-race runs the full go test -race -p 1 ./... suite the same way.
Level 2
Implement a feature
Extend the system within its own patterns.