Replay quarantined items

Who this is for: people who write workflows that process a list, such as devices, users or invoices, where one bad record should not stop the others.

Before you start: you need the Edit workflows permission (edit_workflow) to change a workflow and to replay items of a test run. To replay items of a production run you also need the Activate workflows permission (activate_workflow). Every role can see quarantined items.

A for-each step runs once per item in a list. Normally one item that keeps failing fails the whole step. With quarantine turned on, Liitora sets that item aside (quarantines it), finishes the other items and the later steps, and then marks the run as failed so somebody looks. After you fix the cause, you replay only the items that were set aside.

Turn on quarantine

Add quarantine: true to the step’s strategy:

  - id: update
    name: Update each device in the inventory
    uses: platform/http.request@v1
    connections: { api: inventory }
    retry: { attempts: 3, on: [429, 5xx, timeout, network] }
    strategy:
      for_each: ${{ steps.fetch.outputs.json.devices }}
      quarantine: true
    with:
      method: PUT
      url: "/v1/devices/${{ each.item.id }}"
      json: ${{ each.item }}

What changes:

• Every item runs, even after one fails. fail_fast does not apply.
• An item is quarantined only after it used all its retries.
• The step’s output has null for a quarantined item. Later steps run, so make sure they can handle a null.
• The run ends as Failed with the error code items_quarantined, never as a success, so your alerts still fire.
• If every item fails, nothing is quarantined and the step fails as usual. That usually means a problem with the connection or the step itself, not with one item.

Quarantine is off unless you turn it on.

See what was set aside

1. Open the run. Its error says how many items were quarantined, for example “2 of 50 items of step update were quarantined”.
2. Look at Quarantined items next to the steps. Each item shows its step and position (item 3), its last error with the error code, how many attempts it used and its state:
   • Waiting: it can be replayed.
   • Replaying: a replay run for it is queued or running.
   • Replayed: a replay processed it successfully. It is done.

You can also list them with the MCP tool list_quarantined_items or the API (GET /api/v1/runs/{id}/quarantine).

Replay the items

Fix the cause first, for example the record in the other system or a missing permission. Then:

1. On the run page, under Quarantined items, select Replay on one item, or Replay all for every waiting item.
2. Confirm. Liitora starts a new run and opens it. With Replay all and items in several steps, it starts one run for each step.

A replay run:

• runs only the replayed items of that one step;
• reuses the results of the original run, so nothing else is sent twice;
• does not run the steps after it. If later steps need the fixed items, run the workflow again when you are ready.

If an item fails again, it goes back to Waiting on the original run and you can replay it later. The replay run’s page links back to the original run.

The MCP tool replay_quarantined_items does the same. Give it a run_id, and an item_id for one item.

What keeps this safe

• Two replays of the same item never run at once. The second one gets item_replay_in_progress.
• An item that was replayed successfully is never replayed again (already_replayed).
• Liitora does not keep a copy of the item. It keeps where the item is, its error and a fingerprint. If the item is no longer the same when you replay it, it is not run (item_changed).
• Quarantined items are deleted with their run, and after the same time as your run logs (see Limits per plan).
• Every replay is recorded in the audit log.

Next steps

• Page: Run
• Workflow format: For each
• Read run logs