f508d9873b
## Problem AI assistants were consistently connecting SplitInBatches node outputs backwards because: - Output index 0 = "done" (runs after loop completes) - Output index 1 = "loop" (processes items inside loop) This counterintuitive ordering caused incorrect workflow connections. ## Solution Enhanced the n8n-mcp system to expose and clarify output information: ### Database & Schema - Added `outputs` and `output_names` columns to nodes table - Updated NodeRepository to store/retrieve output information ### Node Parsing - Enhanced NodeParser to extract outputs and outputNames from nodes - Properly handles versioned nodes like SplitInBatchesV3 ### MCP Server - Modified getNodeInfo to return detailed output descriptions - Added connection guidance for each output - Special handling for loop nodes (SplitInBatches, IF, Switch) ### Documentation - Enhanced DocsMapper to inject critical output guidance - Added warnings about counterintuitive output ordering - Provides correct connection patterns for loop nodes ### Workflow Validation - Added validateSplitInBatchesConnection method - Detects reversed connections and provides specific errors - Added checkForLoopBack with depth limit to prevent stack overflow - Smart heuristics to identify likely connection mistakes ## Testing - Created comprehensive test suite (81 tests) - Unit tests for all modified components - Edge case handling for malformed data - Performance testing with large workflows ## Impact AI assistants will now: - See explicit output indices and names (e.g., "Output 0: done") - Receive clear connection guidance - Get validation errors when connections are reversed - Have enhanced documentation explaining the correct pattern Fixes #97 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Database Layer Unit Tests
This directory contains comprehensive unit tests for the database layer components of n8n-mcp.
Test Coverage
node-repository.ts - 100% Coverage ✅
saveNodemethod with JSON serializationgetNodemethod with JSON deserializationgetAIToolsmethodsafeJsonParseprivate method- Edge cases: large JSON, boolean conversion, invalid JSON handling
template-repository.ts - 80.31% Coverage ✅
- FTS5 initialization and fallback
saveTemplatewith sanitizationgetTemplateandgetTemplatesByNodessearchTemplateswith FTS5 and LIKE fallbackgetTemplatesForTaskwith task mapping- Template statistics and maintenance operations
- Uncovered: Some error paths in FTS5 operations
database-adapter.ts - Tested via Mocks
- Interface compliance tests
- PreparedStatement implementation
- Transaction support
- FTS5 detection logic
- Error handling patterns
Test Strategy
The tests use a mock-based approach to:
- Isolate database operations from actual database dependencies
- Test business logic without requiring real SQLite/sql.js
- Ensure consistent test execution across environments
- Focus on behavior rather than implementation details
Key Test Files
node-repository-core.test.ts- Core NodeRepository functionalitytemplate-repository-core.test.ts- Core TemplateRepository functionalitydatabase-adapter-unit.test.ts- DatabaseAdapter interface and patterns
Running Tests
# Run all database tests
npm test -- tests/unit/database/
# Run with coverage
npm run test:coverage -- tests/unit/database/
# Run specific test file
npm test -- tests/unit/database/node-repository-core.test.ts
Mock Infrastructure
The tests use custom mock implementations:
MockDatabaseAdapter- Simulates database operationsMockPreparedStatement- Simulates SQL statement execution- Mock logger and template sanitizer for external dependencies
This approach ensures tests are fast, reliable, and maintainable.