Change history and undo

Every write FireFetch makes is recorded together with the write that would reverse it. Undo replays that inverse.

The history panel

Open it with Cmd/Ctrl+Shift+H. Each entry shows what changed, where, and when. Entries are per database.

What undo covers

Because the inverse is captured at the time of the write, undo handles cases a naive re-write could not:

Operation	What undo restores
Changed a field	The previous value, with its original type
Deleted a field	The field itself, not a null in its place
Deleted a document	The document with all of its fields
Bulk update across many documents	Every document, in one step
Find and replace	Every replacement, in one step

A bulk operation is a single history entry. Undoing a change that touched four thousand documents is one action, not four thousand.

When undo is refused

If a field you are trying to restore has been changed again since your write — by a colleague, or by your application — undoing yours would silently discard their change.

FireFetch detects this and refuses that undo. You are told which fields conflict, and you decide what to do. An undo that quietly destroys someone else’s work is worse than no undo at all.

Concurrent edits

The same principle applies to ordinary editing. When you save a document, FireFetch sends its last-known update time as a precondition. If the document changed after you loaded it, the write fails with a conflict rather than overwriting.

Last-write-wins is convenient right up until the moment it costs you data.

Limits

• History is local to your machine. It records what you did through FireFetch, not everything that happened to the database.
• Undo issues a compensating write, so it counts as a write for both Firestore billing and your FireFetch plan.