What happens when a workflow runs twice or fails halfway?

A retry needs to know what already happened.

An enquiry may arrive twice. A person may approve twice. A connection may fail after part of a workflow has run. These are different situations: before repeating anything, identify the request, the intended action and the evidence of its outcome.

The sample keeps the record and asks again.

In the browser demo, reset and run New job. Check Try a failed connection on this approval, then Approve demo reply. Inspect Connection paused and its history. Select Restore example connection, review the text again and approve. The restore button clears the failure checkbox so the next approval can finish the sample.

What is retained, and what cannot repeat?

Missing information remains missing after restore. If an incomplete enquiry is approved after recovery, it returns to Waiting for details. A retry does not invent an area, confirm a booking or receive a customer’s answer.

A real partial failure is harder.

Imagine a connected workflow updates a job record, then loses the confirmation before recording success locally. Its local status may be uncertain even though the destination changed. Repeating the whole workflow could repeat an external effect.

That is a hypothetical production case; the Fireflax sample does not simulate it. A real implementation needs durable identifiers for requests and intended actions, a retained record of outcomes, checks of the destination and a rule for uncertain results. Browser memory and matching message text alone are not enough.

The offline starter preserves a local file and offers an explicit pause command, but it is still a single-process rehearsal. It does not establish safe concurrent retries, exactly-once delivery, production uptime or rollback across systems.

Use this recovery checklist.

1. Pause and preserve. Stop the relevant workflow through its agreed procedure. Keep the request, versions, error and outcome evidence.
2. Inspect the destination. Check whether the message, record or other intended change happened. Classify it as done, not done or uncertain.
3. Avoid a blind resend. Resolve uncertainty with the responsible person and the system’s evidence. Check the request/action identifiers and duplicate rule.
4. Restore with the permission owner. Fix or reauthorize the actual connection as needed. Restoring access does not authorize replaying every action.
5. Review again. Recheck the latest request and any changed conversation, draft or contact preference. Obtain fresh approval where required.
6. Verify one intended result. Perform only the authorized next action, inspect its outcome and record what happened before resuming normal work.

Name the owner and backup for these steps. A message already sent cannot be unsent by resetting an internal record. Any correction or reversal needs its own permissions and confirmed limits.

Keep the evidence beside the handover.

The retained source and starter runs cover five defined cases each, including repeated approval and failed approval/recovery. They record synthetic inputs, exact states and history. The separate 21-test repository suite also checks missing-information recovery. These finite checks support the descriptions above; they are not a delivery guarantee.