Skip to main content

What is Rollback?

Say agent_pr_workflow ran — it created agent/fix-149, opened a PR, and merged it straight to main by mistake. You need to undo all three steps. One call:

How It Works

rollback() does four things in order:
  1. Loads the receipt by run_id — reads receipts/a1b2c3d4-....json
  2. Verifies the signature — if the receipt was tampered with, rollback refuses to run
  3. Walks actions_taken in reverse — last action first, so nothing is orphaned
  4. Calls the undo action for each step and writes a new rollback receipt

Why Reverse Order?

merge_pr happened last — you have to undo it first before closing the PR makes sense. Reverse order preserves the dependency chain.

The Rollback Receipt

How merge_pr Rollback Works

revert_commit is git revert -m 1 <sha> under the hood — it adds a new commit to main that restores its pre-merge state. Safe on protected branches; no force-push needed. The merge SHA is captured automatically in the receipt when merge_pr runs.
After reverting a merge, if you fix the issue and try to re-merge the same branch, Git will skip those commits (they look already-merged). Run git revert <revert_sha> first — “undo the undo” — then re-merge. This is standard Git behavior, not an Enact quirk.

What If an Action Can’t Be Undone?

Some actions have no safe inverse. If rollback hits one, it stops, records which action couldn’t be reversed, and tells you exactly what to fix manually. It never silently skips. For everything else — see the full rollback table in Connectors.