This is an upstream technical reference retained from the pinned documentation revision. Its diagrams, timings and implementation details are not measurements or release guarantees for Sydekyks. Validate differences against the selected fork release before using it operationally.
Replay and skip: on the first attempt the trigger and step 2 are logged before the worker dies at step 3; on resume a fresh worker skips the logged trigger and step 2, re-runs the in-flight step 3, then continues fresh from step 4 Without it, a worker that dies mid-flow would restart the whole run from the trigger and re-send emails, re-charge cards, and re-call APIs. Instead, a fresh worker reuses the saved output of every finished step and runs only the first step that had not completed. The same mechanism covers crashes, deploys, long pauses, and retries.

​
The run log

Every flow run has a run log: one compressed checkpoint file with everything needed to resume the run on a fresh worker. What is in it:
  • One entry per finished step, keyed by step name: input (secrets hidden), output, status, duration, and the error message for failed steps.
  • Loop iterations and router branches use the same shape, nested under their parent step.
  • Run-level tags.
When it is written:
  • Once at the start, before the first step runs.
  • Every 15 seconds while the run executes, from a background loop that snapshots whatever finished since the last write.
  • Once on the final state (success, failure, or pause).
Each write overwrites the previous copy. Only the latest checkpoint is kept, and the file is compressed before upload.

​
Replay and skip

Resume is not a special path. Each time a worker starts a run, it walks the flow graph from the trigger and asks at every step: is this step’s output already in the log?
  • If yes, and the step finished (SUCCEEDED or PAUSED), the engine returns the saved output and moves on.
  • If no, the engine runs the step, records its output, and continues.
On the first run the log is empty, so every step runs. After a resume the log is full up to the interruption, so the engine skips through all of it and runs only what came next. The most a crash can lose is the single step that was running when the worker died. That step runs again from the last checkpoint, and everything before it is skipped.

​
What triggers a resume

Every interruption resolves through the same replay path. Only the trigger differs.
  • Worker crash or deployment. The queue reassigns the run to another worker, which loads the log and replays.
  • Paused step. The piece creates a waitpoint. When the waitpoint fires, a resume job is queued and a worker replays the run.
  • Retry from a failed step. The same log is reused. The run is re-queued and a worker replays from the failure point.
  • Normal progression within one worker. Same replay model, without leaving the process.