Rewind: undo for Redis writes

Redis is unapologetically destructive. SET overwrites, DEL removes, LPOP pops — and there is no Ctrl+Z. Most of the time that’s fine. The one time it isn’t, it really isn’t.

When you run a write through Varc’s debugger, it first captures a before-image — the exact prior state of the keys that command is about to change. That snapshot is what makes rewind possible.

The safety net isn’t “don’t make mistakes.” It’s “make the mistake reversible.”

What gets captured

Before releasing a held write, Varc records the minimum needed to reconstruct the prior state:

Command	Before-image captured
SET k v	old value + TTL of k (or “did not exist”)
DEL k	full value + type + TTL of k
HSET k f v	prior value of field f (or absent)
LPUSH/RPUSH	the length delta to trim back
EXPIRE k n	the previous TTL

Rewinding replays the inverse:

released:  SET session:42 "{uid:99}" EX 3600
before:    session:42 = "{uid:42}"  ttl=1188
rewind  →  SET session:42 "{uid:42}" EX 1188

What rewind will not pretend to do

Rewind is honest about its limits. It restores the keys a command touched, not the whole database, and it can’t undo effects that already left Redis.

• It won’t reverse a PUBLISH — subscribers already got the message.
• It won’t recover data that expired naturally while you were paused.
• It won’t rewind writes that didn’t go through the debugger — no before-image, no undo.

Within those limits, it’s exactly what you want at 2am: put the key back, and move on.

Where it’s going

Today rewind is per-command and per-session. Next we’re linking before-images into a timeline so you can scrub a whole debugging session backwards — the same model as the interactive stepper, but for state instead of traffic. More on that soon.