Restart a flow
flow_restartRestart a failed or unwanted flow attempt in the same session, preserving all recorded payloads for compliance review. Use when a run goes wrong and you need a fresh try without losing audit data.
Instructions
Abandon this run's current attempt and open a fresh one of the same flow, in the same session. Use it when a run has gone wrong and you want another go: a flow's state is derived by replaying what was exchanged, so a NACKed step or an out-of-sequence callback stays part of the history and flow_start would only resume it. Nothing recorded is destroyed — the abandoned attempt keeps its payloads and stays readable with record_get_payload, because a failed attempt is a compliance finding, not a mistake to erase. The new attempt starts unbound: transaction_id comes back null and the next action mints a fresh one. Prefer this over creating a second session; an abandoned session keeps competing for the participant's callbacks on the endpoint every session shares.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Why this attempt is being abandoned. Recorded against it, and worth supplying — it is what the compliance report can say about the retry. | |
| flow_id | Yes | The flow to restart. Named by flow, never by transaction: the run is what is being restarted, and it may not have a transaction id yet. | |
| session_id | Yes | Session returned by session_create. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| events | No | What has happened in this session since your last call — the participant's callbacks, steps sent automatically, refusals, form submissions. Attached to every session-scoped result and delivered exactly once, so read it here instead of polling. Absent when nothing happened. `more` above zero means call record_get_events for the rest. | |
| attempt | Yes | Which try this is. 1 unless the run has been restarted; every attempt gets its own transaction_id. | |
| flow_id | Yes | Address this run by (session_id, flow_id) from here on. | |
| outcome | Yes | What the first step of the flow needs. | |
| mock_role | Yes | The role this server plays in this flow. | |
| session_id | Yes | ||
| auto_advance | Yes | ||
| callback_url | Yes | What the participant must call back on. Advertised as bap_uri/bpp_uri in every payload this mock sends. | |
| transaction_id | Yes | Null for a new run: the transaction id belongs to whoever sends the flow's first action, so it does not exist until that action crosses the wire. Drive the run with flow_id until then; every loop answer reports the id once it is known. | |
| abandoned_transaction_id | Yes | The transaction the abandoned attempt was running, or null when it never sent anything. Its payloads stay readable with record_get_payload — restarting destroys no evidence. |