Revision history: change sets + revisions + revert — the undo substrate (#48) #61
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  steveandClaude Opus 4.8
|
2dd9f2f04f |
Address Gadfly review on revision history
Build image / build-and-push (push) Successful in 5s
Six real bugs, three of which would have broken the feature's central promise. The worst was that a failed operation threw away the history for changes that had already committed. WithChangeSet buffers HISTORY, not data — the store writes inside fn commit as they go — so discarding the buffer on error left real mutations with no change set and no way to undo them. That is exactly the situation undo exists for: an agent turn that did half a thing and then failed. Now the buffer is written, the summary says the operation failed partway, and the error is still returned. RevertChangeSet does the same for a revert that fails mid-loop. The partial state is still partial, but it is visible and undoable instead of orphaned. versionGuard falsely conflicted whenever one change set held more than one revision for the same entity — an agent turn that moves a bed and then renames it. Each inverse bumps the row's version, so from the second one on the snapshot's version no longer matched the live row and the revert flagged its own work as somebody else's edit. RevertChangeSet now tracks what it has written and the guard compares against that. ListChangeSets found "was this reverted?" with a LEFT JOIN, which emits one duplicate row per revert once a change set has been reverted more than once (undo, redo, undo again). Now a scalar subquery. Reverting an object creation cascade-deleted anything planted in that bed since, quietly. The plops were snapshotted so it was recoverable, but deleting someone's plants as a side effect of an unrelated undo should be reported. It now conflicts and leaves the bed alone. ClearObject cleared by predicate and snapshotted by a separate read, so a plop created between the two was removed with no revision to undo it by. It now clears exactly the ids it read. It also returned an error when only the post-clear re-read failed, which told the caller a clear had failed after it had already applied — inviting a retry of an applied operation. That path now logs the history gap and reports success, matching how record() treats its own write failures. RestoreObject/RestorePlanting could lose the race between the existence check and the insert and surface a raw constraint error. The revert now re-checks and reports ConflictExists, which is what that condition means. RevertChangeSet takes a source, so an agent undoing its own work is distinguishable from a person clicking undo — the whole point of the badge. Refactoring: the three revert bodies repeated a load/guard/unsnapshot/update skeleton (flagged by 3 of 5 models). They are now one generic revertEntity over a small per-type op table, so the ordering, guards and conflict reporting cannot drift apart. The API's view structs duplicated domain types that already carried every field, against the package's direct-JSON convention — dropped. intQuery moved next to the other request helpers. planRevert's comment said three passes where the code runs five. A revert where every revision is already a no-op now answers 200 rather than 201 with a null change set. Six new tests, one per bug. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |
||
|
steveandClaude Opus 4.8
|
b4f3181aef |
Revision history: change sets, revisions, and revert (#48)
The undo substrate. The agent is going to act freely — "empty the garlic bed and plant cucumbers" runs without a confirmation prompt — and that is only a defensible default if the result is easy to roll back. So undo lands before the agent write path, not after it. The unit of undo is the OPERATION, not the row. A change set groups the row-level revisions it produced; revert replays their inverses. Emptying a bed and replanting it touches one object and many plantings, and undoing half of that is worse than useless. Two properties shape the rest: Revert is itself a change set (reverts_id names its target), so history is append-only and an undo can be undone. git revert, not git reset. Revert is version-guarded per entity. Every snapshot carries the row's version; if something edited that row after the change set being reverted, restoring the old snapshot would silently discard the newer edit, so it is reported as a conflict and left alone while the rest of the change set still reverts. The auto-scope is what keeps this invasive but shallow. Service mutations call record(), which joins the change set on the context if one is open and otherwise opens a single-op one on the spot. REST handlers needed no edits at all and every UI mutation lands in history for free; only the agent wraps a whole turn. Multi-row operations (FillRegion, ClearObject) pass all their changes in one record call, so a 12-plop fill is one change set with 12 revisions and one undo. Revisions are buffered and written with their change set in a single transaction, so an operation that fails partway leaves no half-recorded history. Recording is best-effort after the fact: the row is already written, so failing the caller there would report a failure that didn't happen and invite a duplicate retry. A gap is logged loudly instead. Two sharp edges handled explicitly rather than by luck: Deleting an object cascades its plantings away at the FK level, where the service never sees them. deleteObjectRecording snapshots them first, or the delete would be listed in history and not actually be undoable. Restoring deleted rows reuses their ids, and a restored plop needs its object back first. planRevert runs three explicit passes — restore parents then children, then updates, then delete created children before their parents — instead of trusting reverse-seq ordering to happen to be right. Garden deletion stays out of scope, as designed: the cascade is invisible to the service and ON DELETE CASCADE would take the history with it. The history UI will say so rather than pretend otherwise. Closes #48 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |