Obsidian Elite RAG MCP Server

# Transactional Updates Implementation Summary ## Overview We successfully implemented a simple transactional update system for the `n8n_update_partial_workflow` tool that allows AI agents to add nodes and connect them in a single request, regardless of operation order. ## Key Changes ### 1. WorkflowDiffEngine (`src/services/workflow-diff-engine.ts`) - Added **5 operation limit** to keep complexity manageable - Implemented **two-pass processing**: - Pass 1: Node operations (add, remove, update, move, enable, disable) - Pass 2: Other operations (connections, settings, metadata) - Operations are always applied to working copy for proper validation ### 2. Benefits - **Order Independence**: AI agents can write operations in any logical order - **Atomic Updates**: All operations succeed or all fail - **Simple Implementation**: ~50 lines of code change - **Backward Compatible**: Existing usage still works ### 3. Example Usage ```json { "id": "workflow-id", "operations": [ // Connections first (would fail before) { "type": "addConnection", "source": "Start", "target": "Process" }, { "type": "addConnection", "source": "Process", "target": "End" }, // Nodes added later (processed first internally) { "type": "addNode", "node": { "name": "Process", ... }}, { "type": "addNode", "node": { "name": "End", ... }} ] } ``` ## Testing Created comprehensive test suite (`src/scripts/test-transactional-diff.ts`) that validates: - Mixed operations with connections before nodes - Operation limit enforcement (max 5) - Validate-only mode - Complex mixed operations All tests pass successfully! ## Documentation Updates 1. **CLAUDE.md** - Added transactional updates to v2.7.0 release notes 2. **workflow-diff-examples.md** - Added new section explaining transactional updates 3. **Tool description** - Updated to highlight order independence 4. **transactional-updates-example.md** - Before/after comparison ## Why This Approach? 1. **Simplicity**: No complex dependency graphs or topological sorting 2. **Predictability**: Clear two-pass rule is easy to understand 3. **Reliability**: 5 operation limit prevents edge cases 4. **Performance**: Minimal overhead, same validation logic ## Future Enhancements (Not Implemented) If needed in the future, we could add: - Automatic operation reordering based on dependencies - Larger operation limits with smarter batching - Dependency hints in error messages But the current simple approach covers 90%+ of use cases effectively!