Loading challenges
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.
Nobody has started this yet — be first.
No published tickets in this project yet.
About this project
A standalone, payment-agnostic declarative state-machine library (pkg/statemachine) with one concrete application built on top of it: a realistic payment lifecycle (created -> authorized -> captured -> settled -> charged_back, plus failed/expired/voided/refunded) driven entirely by a declarative transition table -- there is no if/switch anywhere else in the codebase deciding what a payment is allowed to do next.
Two engineering problems sit at the center, not the edges: durable per-state timeouts (a UPI-collect payment auto-expires after 5 minutes with no human, webhook, or poll involved, via a SKIP LOCKED sweeper that fires a due timeout exactly once even under many concurrently racing replicas) and crash recovery via a transactional outbox (every side effect owed to the bank/UPI rail is durably queued in the same transaction as the state change, then dispatched by a separate background process with jittered-backoff retry and idempotency keys, so a process kill mid-flight loses nothing). Optimistic concurrency -- a single conditional -- is what actually serializes concurrent writers; there is no anywhere in the payment write path.
Clone it
$git clone https://github.com/nishant1821/GolangDevTraining.gitHow to run it locally, step by step.
UPDATE ... WHERE version = $expectedVersionSELECT ... FOR UPDATETwenty-five tickets are deliberately injected into an otherwise fully-verified, Docker-proven codebase: some are one-character bugs (a flipped comparison operator, a typo'd env var name, swapped constants), others are subtle concurrency and correctness bugs that only a deterministic, non-timing-dependent test can reliably catch (a stale-version check that always evaluates true, a missing FOR UPDATE SKIP LOCKED), and the rest are enhancements with a compile-only stub so the codebase and its verification tests build before the real implementation is written. Every ticket has a dedicated Go test that goes green when the fix is correct.