Files
cc-switch/src-tauri/src/commands/mcp.rs

198 lines
6.0 KiB
Rust
Raw Normal View History

refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
#![allow(non_snake_case)]
use std::collections::HashMap;
use serde::Serialize;
use tauri::State;
use crate::app_config::AppType;
use crate::claude_mcp;
refactor(backend): extract MCP service layer with snapshot isolation Extract all MCP business logic from command layer into `services/mcp.rs`, implementing snapshot isolation pattern to optimize lock granularity after RwLock migration in Phase 5. ## Key Changes ### Service Layer (`services/mcp.rs`) - Add `McpService` with 7 methods: `get_servers`, `upsert_server`, `delete_server`, `set_enabled`, `sync_enabled`, `import_from_claude`, `import_from_codex` - Implement snapshot isolation: acquire write lock only for in-memory modifications, clone config snapshot, release lock, then perform file I/O with snapshot - Use conditional cloning: only clone config when sync is actually needed (e.g., when `enabled` flag is true or `sync_other_side` is requested) ### Command Layer (`commands/mcp.rs`) - Reduce to thin wrappers: parse parameters and delegate to `McpService` - Remove all `*_internal` and `*_test_hook` functions (-94 lines) - Each command now 5-10 lines (parameter parsing + service call + error mapping) ### Core Logic Refactoring (`mcp.rs`) - Rename `set_enabled_and_sync_for` → `set_enabled_flag_for` - Remove file sync logic from low-level function, move sync responsibility to service layer for better separation of concerns ### Test Adaptation (`tests/mcp_commands.rs`) - Replace test hooks with direct `McpService` calls - All 5 MCP integration tests pass ### Additional Fixes - Add `Default` impl for `AppState` (clippy suggestion) - Remove unnecessary auto-deref in `commands/provider.rs` and `lib.rs` - Update Phase 4/5 progress in `BACKEND_REFACTOR_PLAN.md` ## Performance Impact **Before**: Write lock held during file I/O (~10ms), blocking all readers **After**: Write lock held only for memory ops (~100μs), file I/O lock-free Estimated throughput improvement: ~2x in high-concurrency read scenarios ## Testing - ✅ All tests pass: 5 MCP commands + 7 provider service tests - ✅ Zero clippy warnings with `-D warnings` - ✅ No behavioral changes, maintains original save semantics Part of Phase 4 (Service Layer Abstraction) of backend refactoring roadmap.
2025-10-28 14:59:28 +08:00
use crate::services::McpService;
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
use crate::store::AppState;
/// 获取 Claude MCP 状态
#[tauri::command]
pub async fn get_claude_mcp_status() -> Result<claude_mcp::McpStatus, String> {
claude_mcp::get_mcp_status().map_err(|e| e.to_string())
}
/// 读取 mcp.json 文本内容
#[tauri::command]
pub async fn read_claude_mcp_config() -> Result<Option<String>, String> {
claude_mcp::read_mcp_json().map_err(|e| e.to_string())
}
/// 新增或更新一个 MCP 服务器条目
#[tauri::command]
pub async fn upsert_claude_mcp_server(id: String, spec: serde_json::Value) -> Result<bool, String> {
claude_mcp::upsert_mcp_server(&id, spec).map_err(|e| e.to_string())
}
/// 删除一个 MCP 服务器条目
#[tauri::command]
pub async fn delete_claude_mcp_server(id: String) -> Result<bool, String> {
claude_mcp::delete_mcp_server(&id).map_err(|e| e.to_string())
}
/// 校验命令是否在 PATH 中可用(不执行)
#[tauri::command]
pub async fn validate_mcp_command(cmd: String) -> Result<bool, String> {
claude_mcp::validate_command_in_path(&cmd).map_err(|e| e.to_string())
}
#[derive(Serialize)]
pub struct McpConfigResponse {
pub config_path: String,
pub servers: HashMap<String, serde_json::Value>,
}
/// 获取 MCP 配置(来自 ~/.cc-switch/config.json
refactor(api): unify AppType parsing with FromStr trait BREAKING CHANGE: Remove support for legacy app_type/appType parameters. All Tauri commands now accept only the 'app' parameter (values: "claude" or "codex"). Invalid app values will return localized error messages with allowed values. This commit addresses code duplication and improves error handling: - Consolidate AppType parsing into FromStr trait implementation * Eliminates duplicate parse_app() functions across 3 command modules * Provides single source of truth for app type validation * Enables idiomatic Rust .parse::<AppType>() syntax - Enhance error messages with localization * Return bilingual error messages (Chinese + English) * Include list of allowed values in error responses * Use structured AppError::localized for better categorization - Add input normalization * Case-insensitive matching ("CLAUDE" → AppType::Claude) * Automatic whitespace trimming (" codex \n" → AppType::Codex) * Improves API robustness against user input variations - Introduce comprehensive unit tests * Test valid inputs with case variations * Test whitespace handling * Verify error message content and localization * 100% coverage of from_str logic - Update documentation * Add CHANGELOG entry marking breaking change * Update README with accurate architecture description * Revise REFACTORING_MASTER_PLAN with migration examples * Remove all legacy app_type/appType references Code Quality Metrics: - Lines removed: 27 (duplicate code) - Lines added: 52 (including tests and docs) - Code duplication: 3 → 0 instances - Test coverage: 0% → 100% for AppType parsing
2025-10-30 12:33:35 +08:00
use std::str::FromStr;
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
#[tauri::command]
#[allow(deprecated)] // 兼容层命令,内部调用已废弃的 Service 方法
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
pub async fn get_mcp_config(
state: State<'_, AppState>,
app: String,
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
) -> Result<McpConfigResponse, String> {
let config_path = crate::config::get_app_config_path()
.to_string_lossy()
.to_string();
refactor(api): unify AppType parsing with FromStr trait BREAKING CHANGE: Remove support for legacy app_type/appType parameters. All Tauri commands now accept only the 'app' parameter (values: "claude" or "codex"). Invalid app values will return localized error messages with allowed values. This commit addresses code duplication and improves error handling: - Consolidate AppType parsing into FromStr trait implementation * Eliminates duplicate parse_app() functions across 3 command modules * Provides single source of truth for app type validation * Enables idiomatic Rust .parse::<AppType>() syntax - Enhance error messages with localization * Return bilingual error messages (Chinese + English) * Include list of allowed values in error responses * Use structured AppError::localized for better categorization - Add input normalization * Case-insensitive matching ("CLAUDE" → AppType::Claude) * Automatic whitespace trimming (" codex \n" → AppType::Codex) * Improves API robustness against user input variations - Introduce comprehensive unit tests * Test valid inputs with case variations * Test whitespace handling * Verify error message content and localization * 100% coverage of from_str logic - Update documentation * Add CHANGELOG entry marking breaking change * Update README with accurate architecture description * Revise REFACTORING_MASTER_PLAN with migration examples * Remove all legacy app_type/appType references Code Quality Metrics: - Lines removed: 27 (duplicate code) - Lines added: 52 (including tests and docs) - Code duplication: 3 → 0 instances - Test coverage: 0% → 100% for AppType parsing
2025-10-30 12:33:35 +08:00
let app_ty = AppType::from_str(&app).map_err(|e| e.to_string())?;
refactor(backend): extract MCP service layer with snapshot isolation Extract all MCP business logic from command layer into `services/mcp.rs`, implementing snapshot isolation pattern to optimize lock granularity after RwLock migration in Phase 5. ## Key Changes ### Service Layer (`services/mcp.rs`) - Add `McpService` with 7 methods: `get_servers`, `upsert_server`, `delete_server`, `set_enabled`, `sync_enabled`, `import_from_claude`, `import_from_codex` - Implement snapshot isolation: acquire write lock only for in-memory modifications, clone config snapshot, release lock, then perform file I/O with snapshot - Use conditional cloning: only clone config when sync is actually needed (e.g., when `enabled` flag is true or `sync_other_side` is requested) ### Command Layer (`commands/mcp.rs`) - Reduce to thin wrappers: parse parameters and delegate to `McpService` - Remove all `*_internal` and `*_test_hook` functions (-94 lines) - Each command now 5-10 lines (parameter parsing + service call + error mapping) ### Core Logic Refactoring (`mcp.rs`) - Rename `set_enabled_and_sync_for` → `set_enabled_flag_for` - Remove file sync logic from low-level function, move sync responsibility to service layer for better separation of concerns ### Test Adaptation (`tests/mcp_commands.rs`) - Replace test hooks with direct `McpService` calls - All 5 MCP integration tests pass ### Additional Fixes - Add `Default` impl for `AppState` (clippy suggestion) - Remove unnecessary auto-deref in `commands/provider.rs` and `lib.rs` - Update Phase 4/5 progress in `BACKEND_REFACTOR_PLAN.md` ## Performance Impact **Before**: Write lock held during file I/O (~10ms), blocking all readers **After**: Write lock held only for memory ops (~100μs), file I/O lock-free Estimated throughput improvement: ~2x in high-concurrency read scenarios ## Testing - ✅ All tests pass: 5 MCP commands + 7 provider service tests - ✅ Zero clippy warnings with `-D warnings` - ✅ No behavioral changes, maintains original save semantics Part of Phase 4 (Service Layer Abstraction) of backend refactoring roadmap.
2025-10-28 14:59:28 +08:00
let servers = McpService::get_servers(&state, app_ty).map_err(|e| e.to_string())?;
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
Ok(McpConfigResponse {
config_path,
servers,
})
}
/// 在 config.json 中新增或更新一个 MCP 服务器定义
/// [已废弃] 该命令仍然使用旧的分应用API会转换为统一结构
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
#[tauri::command]
pub async fn upsert_mcp_server_in_config(
state: State<'_, AppState>,
app: String,
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
id: String,
spec: serde_json::Value,
sync_other_side: Option<bool>,
) -> Result<bool, String> {
use crate::app_config::McpServer;
refactor(api): unify AppType parsing with FromStr trait BREAKING CHANGE: Remove support for legacy app_type/appType parameters. All Tauri commands now accept only the 'app' parameter (values: "claude" or "codex"). Invalid app values will return localized error messages with allowed values. This commit addresses code duplication and improves error handling: - Consolidate AppType parsing into FromStr trait implementation * Eliminates duplicate parse_app() functions across 3 command modules * Provides single source of truth for app type validation * Enables idiomatic Rust .parse::<AppType>() syntax - Enhance error messages with localization * Return bilingual error messages (Chinese + English) * Include list of allowed values in error responses * Use structured AppError::localized for better categorization - Add input normalization * Case-insensitive matching ("CLAUDE" → AppType::Claude) * Automatic whitespace trimming (" codex \n" → AppType::Codex) * Improves API robustness against user input variations - Introduce comprehensive unit tests * Test valid inputs with case variations * Test whitespace handling * Verify error message content and localization * 100% coverage of from_str logic - Update documentation * Add CHANGELOG entry marking breaking change * Update README with accurate architecture description * Revise REFACTORING_MASTER_PLAN with migration examples * Remove all legacy app_type/appType references Code Quality Metrics: - Lines removed: 27 (duplicate code) - Lines added: 52 (including tests and docs) - Code duplication: 3 → 0 instances - Test coverage: 0% → 100% for AppType parsing
2025-10-30 12:33:35 +08:00
let app_ty = AppType::from_str(&app).map_err(|e| e.to_string())?;
// 读取现有的服务器(如果存在)
let existing_server = {
let cfg = state.config.read().map_err(|e| e.to_string())?;
if let Some(servers) = &cfg.mcp.servers {
servers.get(&id).cloned()
} else {
None
}
};
// 构建新的统一服务器结构
let mut new_server = if let Some(mut existing) = existing_server {
// 更新现有服务器
existing.server = spec.clone();
existing.apps.set_enabled_for(&app_ty, true);
existing
} else {
// 创建新服务器
let mut apps = crate::app_config::McpApps::default();
apps.set_enabled_for(&app_ty, true);
// 尝试从 spec 中提取 name否则使用 id
let name = spec
.get("name")
.and_then(|v| v.as_str())
.unwrap_or(&id)
.to_string();
McpServer {
id: id.clone(),
name,
server: spec,
apps,
description: None,
homepage: None,
docs: None,
tags: Vec::new(),
}
};
// 如果 sync_other_side 为 true也启用其他应用
if sync_other_side.unwrap_or(false) {
new_server.apps.claude = true;
new_server.apps.codex = true;
new_server.apps.gemini = true;
}
McpService::upsert_server(&state, new_server)
.map(|_| true)
refactor(backend): extract MCP service layer with snapshot isolation Extract all MCP business logic from command layer into `services/mcp.rs`, implementing snapshot isolation pattern to optimize lock granularity after RwLock migration in Phase 5. ## Key Changes ### Service Layer (`services/mcp.rs`) - Add `McpService` with 7 methods: `get_servers`, `upsert_server`, `delete_server`, `set_enabled`, `sync_enabled`, `import_from_claude`, `import_from_codex` - Implement snapshot isolation: acquire write lock only for in-memory modifications, clone config snapshot, release lock, then perform file I/O with snapshot - Use conditional cloning: only clone config when sync is actually needed (e.g., when `enabled` flag is true or `sync_other_side` is requested) ### Command Layer (`commands/mcp.rs`) - Reduce to thin wrappers: parse parameters and delegate to `McpService` - Remove all `*_internal` and `*_test_hook` functions (-94 lines) - Each command now 5-10 lines (parameter parsing + service call + error mapping) ### Core Logic Refactoring (`mcp.rs`) - Rename `set_enabled_and_sync_for` → `set_enabled_flag_for` - Remove file sync logic from low-level function, move sync responsibility to service layer for better separation of concerns ### Test Adaptation (`tests/mcp_commands.rs`) - Replace test hooks with direct `McpService` calls - All 5 MCP integration tests pass ### Additional Fixes - Add `Default` impl for `AppState` (clippy suggestion) - Remove unnecessary auto-deref in `commands/provider.rs` and `lib.rs` - Update Phase 4/5 progress in `BACKEND_REFACTOR_PLAN.md` ## Performance Impact **Before**: Write lock held during file I/O (~10ms), blocking all readers **After**: Write lock held only for memory ops (~100μs), file I/O lock-free Estimated throughput improvement: ~2x in high-concurrency read scenarios ## Testing - ✅ All tests pass: 5 MCP commands + 7 provider service tests - ✅ Zero clippy warnings with `-D warnings` - ✅ No behavioral changes, maintains original save semantics Part of Phase 4 (Service Layer Abstraction) of backend refactoring roadmap.
2025-10-28 14:59:28 +08:00
.map_err(|e| e.to_string())
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
}
/// 在 config.json 中删除一个 MCP 服务器定义
#[tauri::command]
pub async fn delete_mcp_server_in_config(
state: State<'_, AppState>,
_app: String, // 参数保留用于向后兼容,但在统一结构中不再需要
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
id: String,
) -> Result<bool, String> {
McpService::delete_server(&state, &id).map_err(|e| e.to_string())
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
}
/// 设置启用状态并同步到客户端配置
#[tauri::command]
#[allow(deprecated)] // 兼容层命令,内部调用已废弃的 Service 方法
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
pub async fn set_mcp_enabled(
state: State<'_, AppState>,
app: String,
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
id: String,
enabled: bool,
) -> Result<bool, String> {
refactor(api): unify AppType parsing with FromStr trait BREAKING CHANGE: Remove support for legacy app_type/appType parameters. All Tauri commands now accept only the 'app' parameter (values: "claude" or "codex"). Invalid app values will return localized error messages with allowed values. This commit addresses code duplication and improves error handling: - Consolidate AppType parsing into FromStr trait implementation * Eliminates duplicate parse_app() functions across 3 command modules * Provides single source of truth for app type validation * Enables idiomatic Rust .parse::<AppType>() syntax - Enhance error messages with localization * Return bilingual error messages (Chinese + English) * Include list of allowed values in error responses * Use structured AppError::localized for better categorization - Add input normalization * Case-insensitive matching ("CLAUDE" → AppType::Claude) * Automatic whitespace trimming (" codex \n" → AppType::Codex) * Improves API robustness against user input variations - Introduce comprehensive unit tests * Test valid inputs with case variations * Test whitespace handling * Verify error message content and localization * 100% coverage of from_str logic - Update documentation * Add CHANGELOG entry marking breaking change * Update README with accurate architecture description * Revise REFACTORING_MASTER_PLAN with migration examples * Remove all legacy app_type/appType references Code Quality Metrics: - Lines removed: 27 (duplicate code) - Lines added: 52 (including tests and docs) - Code duplication: 3 → 0 instances - Test coverage: 0% → 100% for AppType parsing
2025-10-30 12:33:35 +08:00
let app_ty = AppType::from_str(&app).map_err(|e| e.to_string())?;
refactor(backend): extract MCP service layer with snapshot isolation Extract all MCP business logic from command layer into `services/mcp.rs`, implementing snapshot isolation pattern to optimize lock granularity after RwLock migration in Phase 5. ## Key Changes ### Service Layer (`services/mcp.rs`) - Add `McpService` with 7 methods: `get_servers`, `upsert_server`, `delete_server`, `set_enabled`, `sync_enabled`, `import_from_claude`, `import_from_codex` - Implement snapshot isolation: acquire write lock only for in-memory modifications, clone config snapshot, release lock, then perform file I/O with snapshot - Use conditional cloning: only clone config when sync is actually needed (e.g., when `enabled` flag is true or `sync_other_side` is requested) ### Command Layer (`commands/mcp.rs`) - Reduce to thin wrappers: parse parameters and delegate to `McpService` - Remove all `*_internal` and `*_test_hook` functions (-94 lines) - Each command now 5-10 lines (parameter parsing + service call + error mapping) ### Core Logic Refactoring (`mcp.rs`) - Rename `set_enabled_and_sync_for` → `set_enabled_flag_for` - Remove file sync logic from low-level function, move sync responsibility to service layer for better separation of concerns ### Test Adaptation (`tests/mcp_commands.rs`) - Replace test hooks with direct `McpService` calls - All 5 MCP integration tests pass ### Additional Fixes - Add `Default` impl for `AppState` (clippy suggestion) - Remove unnecessary auto-deref in `commands/provider.rs` and `lib.rs` - Update Phase 4/5 progress in `BACKEND_REFACTOR_PLAN.md` ## Performance Impact **Before**: Write lock held during file I/O (~10ms), blocking all readers **After**: Write lock held only for memory ops (~100μs), file I/O lock-free Estimated throughput improvement: ~2x in high-concurrency read scenarios ## Testing - ✅ All tests pass: 5 MCP commands + 7 provider service tests - ✅ Zero clippy warnings with `-D warnings` - ✅ No behavioral changes, maintains original save semantics Part of Phase 4 (Service Layer Abstraction) of backend refactoring roadmap.
2025-10-28 14:59:28 +08:00
McpService::set_enabled(&state, app_ty, &id, enabled).map_err(|e| e.to_string())
refactor(backend): phase 2 - split commands.rs by domain (100%) Split monolithic commands.rs (1525 lines) into 7 domain-focused modules to improve maintainability and readability while preserving the external API. ## Changes ### Module Structure Created `commands/` directory with domain-based organization: - **provider.rs** (946 lines, 15 commands) - Provider CRUD operations (get, add, update, delete, switch) - Usage query integration - Endpoint speed testing and custom endpoint management - Sort order management - Largest file but highly cohesive (all provider-related) - **mcp.rs** (235 lines, 13 commands) - Claude MCP management (~/.claude.json) - SSOT MCP config management (config.json) - Sync operations (Claude ↔ Codex) - Import/export functionality - **config.rs** (153 lines, 8 commands) - Config path queries (Claude/Codex) - Directory operations (open, pick) - Config status checks - Parameter compatibility layer (app_type/app/appType) - **settings.rs** (40 lines, 5 commands) - App settings management - App restart functionality - app_config_dir override (Store integration) - **plugin.rs** (36 lines, 4 commands) - Claude plugin management (~/.claude/config.json) - Plugin status and config operations - **misc.rs** (45 lines, 3 commands) - External link handling - Update checks - Portable mode detection - **mod.rs** (15 lines) - Module exports via `pub use` - Preserves flat API structure ### API Preservation - Used `pub use` pattern to maintain external API - All commands still accessible as `commands::function_name` - Zero breaking changes for frontend code - lib.rs invoke_handler unchanged (48 commands registered) ## Statistics - Files: 1 → 7 (modular organization) - Lines: 1525 → 1470 (net -55 lines, -3.6%) - Commands: 48 → 48 (all preserved) - Average file size: 210 lines (excluding provider.rs) - Compilation: ✅ Success (6.92s, 0 warnings) - Tests: ✅ 4/4 passed ## Benefits - **Maintainability**: Easier to locate and modify domain-specific code - **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines - **Testability**: Can unit test individual modules in isolation - **Scalability**: Clear pattern for adding new command groups - **Zero Risk**: No API changes, all tests passing ## Design Decisions 1. **Domain-based split**: Organized by business domain (provider, mcp, config) rather than technical layers (crud, query, sync) 2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion (all provider-related operations together). Can be further split in Phase 2.1 if needed. 3. **Parameter compatibility**: Retained multiple parameter names (app_type, app, appType) for backward compatibility with different frontend call styles ## Phase 2 Status: ✅ 100% Complete Ready for Phase 3: Adding integration tests. Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
}
feat(mcp): implement unified MCP management for v3.7.0 BREAKING CHANGE: Migrate from app-specific MCP storage to unified structure ## Phase 1: Data Structure Migration - Add McpApps struct with claude/codex/gemini boolean fields - Add McpServer struct for unified server definition - Add migration logic in MultiAppConfig::migrate_mcp_to_unified() - Integrate automatic migration into MultiAppConfig::load() - Support backward compatibility through Optional fields ## Phase 2: Backend Services Refactor - Completely rewrite services/mcp.rs for unified management: * get_all_servers() - retrieve all MCP servers * upsert_server() - add/update unified server * delete_server() - remove server * toggle_app() - enable/disable server for specific app * sync_all_enabled() - sync to all live configs - Add single-server sync functions to mcp.rs: * sync_single_server_to_claude/codex/gemini() * remove_server_from_claude/codex/gemini() - Add read_mcp_servers_map() to claude_mcp.rs and gemini_mcp.rs - Add new Tauri commands to commands/mcp.rs: * get_mcp_servers, upsert_mcp_server, delete_mcp_server * toggle_mcp_app, sync_all_mcp_servers - Register new commands in lib.rs ## Migration Strategy - Detects old structure (mcp.claude/codex/gemini.servers) - Merges into unified mcp.servers with apps markers - Handles conflicts by merging enabled apps - Clears old structures after migration - Saves migrated config automatically ## Known Issues - Old commands still need compatibility layer (WIP) - toml_edit type conversion needs fixing (WIP) - Frontend not yet implemented (Phase 3 pending) Related: v3.6.2 -> v3.7.0
2025-11-14 12:51:24 +08:00
// ============================================================================
// v3.7.0 新增:统一 MCP 管理命令
// ============================================================================
use crate::app_config::McpServer;
/// 获取所有 MCP 服务器(统一结构)
#[tauri::command]
pub async fn get_mcp_servers(
state: State<'_, AppState>,
) -> Result<HashMap<String, McpServer>, String> {
McpService::get_all_servers(&state).map_err(|e| e.to_string())
}
/// 添加或更新 MCP 服务器
#[tauri::command]
pub async fn upsert_mcp_server(
state: State<'_, AppState>,
server: McpServer,
) -> Result<(), String> {
McpService::upsert_server(&state, server).map_err(|e| e.to_string())
}
/// 删除 MCP 服务器
#[tauri::command]
pub async fn delete_mcp_server(state: State<'_, AppState>, id: String) -> Result<bool, String> {
feat(mcp): implement unified MCP management for v3.7.0 BREAKING CHANGE: Migrate from app-specific MCP storage to unified structure ## Phase 1: Data Structure Migration - Add McpApps struct with claude/codex/gemini boolean fields - Add McpServer struct for unified server definition - Add migration logic in MultiAppConfig::migrate_mcp_to_unified() - Integrate automatic migration into MultiAppConfig::load() - Support backward compatibility through Optional fields ## Phase 2: Backend Services Refactor - Completely rewrite services/mcp.rs for unified management: * get_all_servers() - retrieve all MCP servers * upsert_server() - add/update unified server * delete_server() - remove server * toggle_app() - enable/disable server for specific app * sync_all_enabled() - sync to all live configs - Add single-server sync functions to mcp.rs: * sync_single_server_to_claude/codex/gemini() * remove_server_from_claude/codex/gemini() - Add read_mcp_servers_map() to claude_mcp.rs and gemini_mcp.rs - Add new Tauri commands to commands/mcp.rs: * get_mcp_servers, upsert_mcp_server, delete_mcp_server * toggle_mcp_app, sync_all_mcp_servers - Register new commands in lib.rs ## Migration Strategy - Detects old structure (mcp.claude/codex/gemini.servers) - Merges into unified mcp.servers with apps markers - Handles conflicts by merging enabled apps - Clears old structures after migration - Saves migrated config automatically ## Known Issues - Old commands still need compatibility layer (WIP) - toml_edit type conversion needs fixing (WIP) - Frontend not yet implemented (Phase 3 pending) Related: v3.6.2 -> v3.7.0
2025-11-14 12:51:24 +08:00
McpService::delete_server(&state, &id).map_err(|e| e.to_string())
}
/// 切换 MCP 服务器在指定应用的启用状态
#[tauri::command]
pub async fn toggle_mcp_app(
state: State<'_, AppState>,
server_id: String,
app: String,
enabled: bool,
) -> Result<(), String> {
let app_ty = AppType::from_str(&app).map_err(|e| e.to_string())?;
McpService::toggle_app(&state, &server_id, app_ty, enabled).map_err(|e| e.to_string())
}