Start
Use /track/start/ with the target record and
state-machine description, under permissions that can access the
required objects.
State tracking guide
Define which record transitions are valid.
Store a state-machine description, enable tracking for the table, start a state instance, and submit named events through the tracking endpoints.
- States
- Events
- History
Describe the allowed path.
StateMachineDescriptions:
- Name: order_lifecycle
InitialState: pending
Events:
- Name: confirm
Src: [pending]
Dst: confirmed
- Name: ship
Src: [confirmed]
Dst: shipped
- Name: cancel
Src: [pending, confirmed]
Dst: cancelled
Set IsStateTrackingEnabled: true on the application
table. Daptin creates its companion state table, including current
state, links to the record and state-machine description, and user
tracking fields.
Start and transition.
Apply an event
Send the named event to /track/event/. Its current
state must appear in the event's source list.
Reject invalid jumps
Attempt shipping from pending or repeating a one-way event and verify that current state remains unchanged.
Read history
Inspect the companion state records to explain which accepted events moved the record to its current state.
Keep validation separate from side effects.
State tracking validates and records transitions. It does not define entry or exit handlers and does not automatically invoke a Daptin action when an event succeeds. When confirming an order must also reserve stock or send mail, expose a permissioned action that performs the required work and explicitly applies the transition.
- Every initial state and event name is unique and intentional.
- Every destination is reachable through an allowed source.
- Invalid and repeated transitions fail without changing state.
- The start and event endpoints are denied to unintended callers.
- History identifies the record, state-machine description, user, and accepted path.
- Action failures do not leave business side effects and state misleadingly out of sync.