Runs & events
When a scenario runs, Mockflow records every step as an event: a request leaving a component, a cache miss, a retry, a response arriving. Events are the story of the run — ordered, complete, and replayable.
What an event is
Each event captures one moment: when it happened (in virtual milliseconds since the run started), what kind of step it was, which component, connection, or token it involves, and a short plain-text summary. Events are immutable — once a run finishes, its events never change, which is what makes replay trustworthy.
Events come grouped into stages — chapters of the story, like “authorize the customer” — so a long transcript stays readable.
Where to read them
After a run, the workbench dock shows three views. Transcript is the ordered list: each row shows the virtual time, the event kind, the token, and its summary, under stage headings. Timeline lays the same events out over time with a filter bar — its Next warning or error button jumps straight to the first problem. Inspect shows full details of the selected event.
A transcript excerpt, in plain words
Replay and pause at useful moments
Use the playback controls to play, pause, step forward or backward, jump between stages, and change the speed. The canvas highlights the part of the system involved in the selected event.
Breakpoints pause playback when something you care about happens. You can pause at a component, a stage, a kind of event, an error, or a simple condition. Breakpoints change only how you review a completed run; they do not change the result.
The kinds of events
You do not need to memorize these names. They appear in the timeline and transcript, and the selected event includes a plain summary. This table is a reference when you want more detail:
| Group | Event kinds | What they tell you |
|---|---|---|
| Run lifecycle | RUN_STARTED · RUN_COMPLETED · RUN_FAILED · RUN_CANCELLED · RUN_GUARD_TRIGGERED | The run itself starting and finishing — including being stopped by you or by a safety limit. |
| Movement | TOKEN_EMITTED · TOKEN_COMPLETED · EDGE_TRAVERSE_STARTED · EDGE_TRAVERSE_COMPLETED · NODE_ENTERED · NODE_EXITED | A token is one piece of traffic — a request making its way through the system. These events trace it moving along connections and through components. |
| Calls & responses | CALL_STARTED · CALLER_WAITING · RESPONSE_SENT · RESPONSE_RECEIVED · CALL_COMPLETED | One component asking another and getting its answer — including the time spent waiting. |
| Routing & data shaping | ROUTE_EVALUATED · ROUTE_SELECTED · SCHEMA_VALIDATED · TRANSFORM_APPLIED | A gateway choosing a route, and data being checked or reshaped on the way through. |
| Databases & caches | DB_READ · DB_RESULT · CACHE_LOOKUP · CACHE_HIT · CACHE_MISS · CACHE_WRITE · CACHE_DELETE · CACHE_EXPIRED | Reads, writes, and lookups — including whether a cache lookup hit or missed. |
| Queues | QUEUE_ENQUEUED · QUEUE_AVAILABLE · QUEUE_DEQUEUED · MESSAGE_ACKED · MESSAGE_REQUEUED · MESSAGE_DEAD_LETTERED | A message's life in a queue: waiting, being picked up, succeeding, being retried, or ending up in the dead-letter queue. |
| Topics & joins | TOPIC_PUBLISHED · TOKEN_FORKED · JOIN_ARRIVED · JOIN_SATISFIED · JOIN_TIMED_OUT · TOKEN_JOINED | Fan-out and fan-in: a topic broadcasting an event as one forked child token per subscriber, and a join collecting related branches until enough of them have arrived. |
| Workflows | WORKFLOW_STARTED · WORKFLOW_STEP_STARTED · WORKFLOW_STEP_COMPLETED · WORKFLOW_STEP_FAILED · WORKFLOW_COMPENSATED · WORKFLOW_COMPLETED · WORKFLOW_FAILED | A workflow running its steps in order — each step starting and finishing, and the whole saga completing or failing. |
| Object storage | OBJECT_PUT · OBJECT_GET · OBJECT_MISSING · OBJECT_DELETED | Objects being stored, fetched, found missing, or deleted in an object storage component. |
| Waiting & retries | WAIT_STARTED · WAIT_COMPLETED · RETRY_SCHEDULED · RETRY_STARTED · RETRY_EXHAUSTED | Timers running, and retry attempts being scheduled, tried, and eventually given up on. |
| Errors & state | ERROR_RAISED · ERROR_HANDLED · STATE_PATCH_APPLIED | Failures being raised and handled, and stored state changing as a result of the run. |
Every event has a severity — information or error. Filtering the timeline to errors first, then replaying the events just before them, is the fastest way to understand a failed run.