RECOVERY GUIDE · CONFLICTS
A later edit should stop an older undo.
Restoring an old snapshot can erase someone’s newer work. Rewind’s supported connectors use a version check to decide whether the recorded change is still safe to reverse.
Why matching values are not enough.
Imagine an automation sets a customer status from active to inactive. A teammate later edits the same row. Writing the old snapshot back without checking could overwrite a decision made after the automation ran.
There is a subtler case too: a value changes, then changes back to inactive. Its visible value matches the capture, but there were intervening writes. Comparing values alone misses that history.
Supabase checks the revision as well.
Registering a supported table adds a rewind_revision UUID and a trigger that rotates it on every insert or update. Capture returns the post-update revision. Recovery expects that exact revision and the recorded after values.
The restore function locks the row, checks both, and updates it within one transaction. If a newer write happened, the revision differs and the old restore is rejected. This also means unrelated edits, no-op updates and changes later changed back block an older undo.
What to do when recovery stops.
- Inspect the actual current row and the original workflow execution.
- Identify the intervening change and who or what made it.
- Preserve the newer edit while deciding the intended final state.
- If a correction is still needed, make a new, deliberate update. Do not alter the old receipt or substitute a fresh version to bypass the conflict.
For a workflow run, a conflict stops the remaining recovery steps. Earlier steps may already have restored, so review all affected records before resuming work.
Verify the protection on disposable data.
- Complete the n8n + Supabase setup and capture a test update.
- Edit the demo row directly in Supabase after capture.
- Approve the recorded undo and run the recovery worker once.
- Confirm Rewind reports a conflict and Supabase still has the newer value.
For a supported HTTP API, the matching worker instead requires strong ETags and atomic conditional writes. A timestamp or a last-second read alone is not equivalent. Provider semantics must satisfy that contract before connecting real data.