Skip to main content
Glama

MCP Console Automation Server

by ooples
ARCHITECTURE_REFACTOR_README.md7.6 kB
# MCP Console Automation - Architecture Refactoring Project ## Project Overview This is a comprehensive refactoring project with two primary objectives: 1. **Fix Session Management Issues**: Resolve "stream destroyed" and "Session not found" errors that were occurring with console automation 2. **Improve Architecture**: Extract the 64 protocols from the monolithic ConsoleManager.ts into a clean, maintainable architecture with proper separation of concerns The project combines critical bug fixes with architectural improvements to create a robust, production-ready system. ## Current State - **Codebase**: 10,000+ lines of working code with all 64 protocols embedded in ConsoleManager.ts - **Status**: Fully functional but monolithic architecture - **Protocols**: 64 different console/connection protocols (SSH, Docker, Kubernetes, Azure, AWS, etc.) - **Tests**: Working test suite that validates core functionality - **Compilation**: Clean compilation with TypeScript ## Project Goals ### Primary Objectives 1. **Fix Session Management Issues**: - Resolve "stream destroyed" errors when creating sessions - Fix "Session not found" errors in MCP operations - Implement proper one-shot vs persistent session detection - Add comprehensive diagnostics for session lifecycle tracking 2. **Clean Architecture**: Extract protocols into separate files with proper interfaces 3. **Maintain 100% Functionality**: All existing features must continue to work exactly as before 4. **Type Safety**: Maintain strict TypeScript compilation with no errors 5. **Testability**: Ensure all functionality remains testable 6. **Maintainability**: Create code that's easier to understand and modify ### Non-Goals - **No Feature Additions**: We are NOT adding new features, only reorganizing existing code - **No API Changes**: External interfaces must remain identical - **No Performance Degradation**: System must perform at least as well as before ## Technical Approach ### Phase-by-Phase Implementation We will implement this in 10 sequential phases, testing after each phase: 1. **Phase 1**: Analyze existing codebase, implement session management fixes, and create proper interface definitions 2. **Phase 2**: Create BaseProtocol base class with session lifecycle management that works with existing code 3. **Phase 3**: Refactor SSH/Terminal protocols (SSH, Telnet, Serial) 4. **Phase 4**: Refactor Container protocols (Docker, Kubernetes, LXC, Podman) 5. **Phase 5**: Refactor Cloud protocols (AWS SSM, Azure, GCP) 6. **Phase 6**: Refactor Database protocols (MySQL, PostgreSQL, MongoDB, etc.) 7. **Phase 7**: Refactor remaining protocols (VNC, RDP, WinRM, etc.) 8. **Phase 8**: Update ConsoleManager to use extracted protocols 9. **Phase 9**: Comprehensive integration testing 10. **Phase 10**: Test real-world functionality (SSH to GitHub runner) ### Architectural Principles #### Interface Design - **IProtocol**: Common interface all protocols must implement - **BaseProtocol**: Base class providing common functionality - **Protocol-Specific Interfaces**: Each protocol type can extend base interfaces as needed #### Key Requirements - All protocols must implement the same core methods - Error handling must be consistent across protocols - Session management must work uniformly - Connection pooling and keep-alive functionality must be preserved #### File Organization ``` src/ ├── core/ │ ├── ConsoleManager.ts # Main orchestrator (simplified) │ ├── IProtocol.ts # Protocol interface definition │ ├── BaseProtocol.ts # Common protocol base class │ └── ProtocolRegistry.ts # Protocol registration system ├── protocols/ │ ├── ssh/ │ │ ├── SSHProtocol.ts # SSH implementation │ │ └── SSHTypes.ts # SSH-specific types │ ├── docker/ │ │ ├── DockerProtocol.ts # Docker implementation │ │ └── DockerTypes.ts # Docker-specific types │ └── ... (one directory per protocol family) └── types/ ├── index.ts # Common types ├── protocols.ts # Protocol-specific type unions └── sessions.ts # Session management types ``` ## Critical Success Factors ### Must-Have Requirements 1. **Session Management Fixed**: No more "stream destroyed" or "Session not found" errors 2. **Zero Regression**: All existing functionality must work exactly as before 3. **Clean Compilation**: TypeScript must compile without errors or warnings 4. **Test Coverage**: All tests must pass, including comprehensive session management tests 5. **Real-World Validation**: Must successfully connect to GitHub runner via SSH to debug autoscaler queue issues ### Quality Gates - After each phase, run: `npm run lint && npm run typecheck` - After each phase, run the full test suite - Before final completion, test actual SSH connection to GitHub runner - Each protocol extraction must maintain identical external behavior ## Testing Strategy ### Automated Testing - Unit tests for each extracted protocol - Integration tests for ConsoleManager with new architecture - Regression tests to ensure no functionality loss - Performance tests to validate no degradation ### Manual Testing - SSH connection to GitHub runner server - Verification that session management works correctly - Error handling validation - Connection pooling and keep-alive verification ## Implementation Rules ### Code Quality Standards 1. **No Separate "Improved" Versions**: Always modify original files directly 2. **Production-Ready Code**: No shortcuts or temporary solutions 3. **Comprehensive Error Handling**: Maintain existing error recovery mechanisms 4. **Documentation**: Code must be self-documenting with clear interfaces ### Git Workflow - Work on clean backup codebase (current state) - Commit after each successful phase - Use descriptive commit messages - Maintain single source of truth for each component ## Expected Outcomes ### Short-Term (End of Refactoring) - Clean, maintainable codebase with separated concerns - 64 protocol implementations in their own files - Proper TypeScript interfaces and inheritance - All existing functionality preserved ### Long-Term Benefits - Easier to add new protocols - Simplified debugging and maintenance - Better code reusability - Improved testability and reliability ## Risk Mitigation ### Potential Risks - Breaking existing functionality during extraction - Type conflicts between protocols - Performance impact from architectural changes - Integration issues with existing dependencies ### Mitigation Strategies - Sequential implementation with testing after each phase - Maintain identical external APIs - Preserve all existing error handling and recovery mechanisms - Use existing working patterns as templates for new structure ## Success Metrics ### Technical Metrics - Zero TypeScript compilation errors - All existing tests pass - Successful SSH connection to GitHub runner - No performance degradation (measured via benchmarks) ### Code Quality Metrics - Reduced file size of ConsoleManager.ts (from 10,000+ lines to manageable size) - Proper separation of concerns (each protocol in its own file) - Consistent interface implementation across all protocols - Maintainable code structure --- **Current Phase**: Phase 1 - Analyzing existing codebase and designing proper interfaces **Next Milestone**: Complete Phase 1 with working IProtocol and BaseProtocol definitions

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ooples/mcp-console-automation'

If you have feedback or need assistance with the MCP directory API, please join our Discord server