Untracked Actions — Undo/Redo History

Untracked State Categories

Category	Reason Not Tracked
Viewport (pan, zoom)	Transient camera position — users expect free navigation, not undo on pan
Canvas mode transitions	Mode reflects the user's intent (view vs. edit) — not a reversible mutation
Node selection	Selection is UI state, not data state — restoring it post-undo would be confusing
Config form edits	Auto-saved directly via persistence middleware; separate undo semantics would conflict
Execution state (statuses, logs)	Read-only in execution mode; comes from backend, cannot be "undone"
loadWorkflow / deserializeWorkflow	A full reload resets history stack — no partial undo into a previous session

Untracked updateNode Calls

// Config field changes go through updateNode but bypass historyAction
updateNode: (id, patch) => {
    // NOTE: This call does NOT use historyAction — it writes directly to the store
    // and triggers the persistence middleware (auto-save)
    set(state => ({
        nodes: state.nodes.map(n =>
            n.id === id ? { ...n, ...patch } : n
        )
    }));
    // Auto-save fires here — no undo entry created
}

Why Config Edits Are Not Undoable

Config fields are auto-saved to the server on every keystroke (debounced). By the time the user presses Ctrl+Z, the server already has the new value.
Making config edits undoable would require client-side optimistic rollback + server-side revert — significantly more complex.
Config fields have their own reset mechanism: the "Reset to defaults" button in each config form panel.

User expectation alignment: Users typically expect Ctrl+Z on a canvas to undo structural changes (dragging, connecting, deleting nodes) — not text they typed into a form field. This mirrors the UX pattern of tools like Figma and Miro where canvas structure is undoable but property panel edits are not.

← Tracked Actions Next: Undo (Ctrl+Z) →