How to undo a captured Supabase update.

Check the prerequisites.

The table and fields must be opted into the Supabase connector, and the original write must have used its capture function. The actual returned snapshots and revision must have reached Rewind. You also need a matching recovery worker configured for that Supabase project.

The connector supports selected existing, non-null scalar fields on registered tables. It does not restore deleted rows, undo insertions, reverse emails or payments, or reverse trigger side effects in other records. Set up a disposable test first.

Review the recorded change.

Open Workflows → All changes in your Rewind workspace. Confirm the resource, selected fields, before values and after values. For a single recorded update, preview its undo and approve only if those original values are the intended result.

Changes grouped into a workflow run are reviewed through that run’s recovery plan. Complete and close the history first. Workers restore supported steps in reverse order; this is not one atomic transaction across services.

Run the worker and inspect its report.

Approval queues a recovery job. Your worker claims it, checks the current resource and attempts a conditional restore. For Supabase, the connector checks the revision and recorded after values while holding the row lock in the restore transaction.

Restored · worker reported

The worker reported success. Verify the row directly in Supabase before resuming the original workflow.

Later change protected

The record no longer matches the captured version. The old undo must not overwrite the newer edit.

Outcome unknown

A request may have reached the provider without a confirmed response. Stop automated recovery and inspect the original worker execution and provider history before any further write.

Do not turn a retry into another change.

The provider write and recording call are separate transactions. If only recording failed, retry delivery of the saved receipt, not the business action. A successful update can remain unrecorded if its response or captured output is lost before delivery.

Do not replace a stale revision with the current one to force an old undo through. If you need a different final state, investigate and make a new, intentional correction after resolving any unknown outcome.

Test the failure path too.

A restoration alone does not prove that later work is safe. On a disposable row, capture a fresh update, change the row again and attempt recovery. Confirm the worker reports a conflict and leaves the newer value intact. Understand rollback conflicts.