Handlers
A handler tells a component what to do when something arrives at one of its input ports: call this, wait for that, then reply. Handlers are built from a short list of simple actions — no code required.
Where handlers live
Select a component and open the Behavior tab in the Inspector. Under Arrival handlers you’ll see one card per input port — “On request in”, “On event”, and so on. Ports without a handler show an Add handler button. Each handler is an ordered list of actions that run top to bottom, up to 32 per handler.
You usually don’t start from nothing. Components come with sensible default behavior (marked catalog default), and you add or edit handlers only where you want something custom. Handlers you write are marked authored.
The six actions
| Action | What it does |
|---|---|
| call | Send a request along one of your outgoing connections and wait for the result to arrive back at one of your input ports. |
| await | Pause until an earlier request/response interaction finishes, then continue with its result. |
| map | Pass the current payload along to the next action. |
| emit | Send along an outgoing connection and move on without waiting — fire-and-forget, like putting a message on a queue. |
| respond | Send the reply back to whoever called you, along a response connection. |
| fail | Stop and raise a named failure, like dependency_timeout. Great for modeling what happens when things go wrong. |
Want a delay instead? That’s not an action — drop a Timer / delay component into the path and set its duration.
A call pauses its current handler. When the matched return arrives, execution continues with the next action in that same ordered list. The handler attached to the return port does not run for that matched return, so keep post-call work directly after the call.
Run an action conditionally
Choose Run only when… when an action should happen only in a particular situation. You can check information from the current request, the scenario, stored starting data, or the result that just arrived. The form lets you combine several checks and choose whether all or any of them must match.
When a condition does not match, Mockflow skips that action and continues to the next one. Use the field picker in the editor rather than guessing a path.
A worked example: checkout
Here’s the handler on a Checkout service’s request in port. When an order arrives, the service checks the customer, loads the order, hands work to two queues, and replies:
Handler: On request in — Checkout service
- call → Auth service, await the result at “return”
- call → Orders database, await the record at “data result”
- map → pass the order along unchanged
- emit → Fulfillment queue (fire-and-forget)
- emit → Notifications queue (fire-and-forget)
- respond → back to the API Gateway
Order matters: the response in step 6 goes out only after both calls have come back. If the Auth service failed instead, a fail action (or the error path in your diagram) decides what the customer sees — and the whole story shows up as events when you run it.
Handlers vs. component settings
The Behavior tab also holds each component’s settings — simple knobs rather than steps. A cache has a TTL, a service has a work duration, a queue has maximum attempts and backoff, an external dependency has a success-or-failure mode. Settings say how a component does its job; handlers say what it does when traffic arrives. Together with connections, they’re the whole behavior of your system.