mix continuum.replay (continuum v0.8.1)

Copy Markdown View Source

Replays a durable run's journaled history against the code on this node.

mix continuum.replay <run_id> --repo MyApp.Repo
mix continuum.replay <run_id> --repo MyApp.Repo --format json
mix continuum.replay <run_id> --repo MyApp.Repo --no-snapshot
mix continuum.replay <run_id> --repo MyApp.Repo --against MyApp.Orders.Checkout
mix continuum.replay <run_id> --repo MyApp.Repo --strict

Nothing is written. The run keeps its lease, its history, and its pending signals; see Continuum.Replay for why that takes a dedicated journal adapter rather than a flag.

Use it on a run that is wedged, or on one that failed with a Continuum.ReplayDriftError, to get back one of:

  • completed — the workflow reaches a return value from this history.
  • suspended — it stops at a pending effect, with the reason. A history_exhausted reason names the cursor and the effect it would have performed next.
  • continued — it tail-calls continue_as_new/1.
  • drift — the exact cursor where code and history disagree, with the journaled event and the effect the code asked for.

Options

  • --repo — the Ecto repo to read from. Defaults to :continuum, :repo.
  • --instance — a named runtime instance. Defaults to the default instance.
  • --against — replay against another workflow module, to see what a code change would do to a run already in flight. The journaled version is used when omitted.
  • --no-snapshot — ignore stored snapshots and replay from events alone. Useful for confirming a snapshot and its events agree.
  • --format json — machine-readable output.
  • --strict — exit 1 unless the outcome is completed or suspended.

A version this node cannot load is reported as unknown_version, not as drift: the mismatch is in the deploy, not in the run.