Skip to main content
Glama
freefish1218

MCP HuggingFetch

by freefish1218
OPTIMIZATION_PLAN.md7.66 kB
# MCP HuggingFetch 优化方案 > 基于代码审查结果制定的优化实施计划 > > **创建时间**: 2025-01-25 > **版本**: v1.4.0+ > **状态**: 待实施 ## 概述 本文档针对代码审查发现的问题,按优先级制定详细的优化方案。共识别出8项核心需要改进的问题,分为高优先级和中优先级两个等级。 ## 优化项目分类 ### 🔴 高优先级(必须修复) #### 1. JSON-RPC 错误ID规范合规 **位置**: `src/mcp/server.js:65–70, 126–133` **问题描述**: - 当前使用字面量 `'unknown'` 作为错误响应ID - JSON-RPC 2.0 规范要求:成功时回显请求ID,解析错误时使用 `null` **修复方案**: ```javascript // 当前问题代码 const errorResponse = JsonRpcResponse.error('unknown', JsonRpcError.internalError(error.message)); // 修复方案 const errorResponse = JsonRpcResponse.error( request?.id || null, // 有请求则回显ID,否则使用null JsonRpcError.internalError(error.message) ); ``` **影响**: 协议不合规可能导致客户端混淆或错误处理 #### 2. HTTP 批量请求并发控制缺陷 **位置**: `src/core/http.js:270–273` **问题描述**: - `Promise.race` 完成后删除错误的promise(最后添加的而非已完成的) - 可能导致运行中的任务被提前移除,影响并发控制 **修复方案**: ```javascript // 当前问题代码 if (executing.length >= concurrency) { await Promise.race(executing); executing.splice(executing.findIndex(p => p === promise), 1); } // 修复方案1: 追踪已完成的promise if (executing.length >= concurrency) { const settled = await Promise.race(executing.map((p, i) => p.then(() => i))); executing.splice(settled, 1); } // 修复方案2: 简化为仅使用executeWithConcurrency const results = await Promise.all( tasks.map(task => this.executeWithConcurrency(task)) ); ``` **影响**: 并发控制失效可能导致资源泄漏或性能问题 #### 3. 强制重新下载标志不匹配 **位置**: `src/core/download.js:340`, `src/core/downloader.js:138` **问题描述**: - `downloadFiles` 检查 `options.force_redownload` - 调用者传递 `forceRedownload`(驼峰式) - 工具层使用 `force` 参数 - 导致强制下载功能失效 **修复方案**: ```javascript // 在 downloadFiles 中统一处理多种命名 const shouldForceRedownload = options.force_redownload || options.forceRedownload || options.force || false; const pendingTasks = shouldForceRedownload ? tasks : tasks.filter(task => !task.isCompleted()); ``` **影响**: 用户无法强制重新下载文件 #### 4. 下载队列并发参数不生效 **位置**: `src/core/downloader.js:58–64, 118–142` **问题描述**: - `maxConcurrent` 参数传递给 `downloadFiles` - 但 `DownloadQueue` 的并发数固定为构造器中的值(5) - 用户设置的 `max_concurrent` 被忽略 **修复方案**: ```javascript // 在 DownloadQueue 中添加动态设置方法 class DownloadQueue { setMaxConcurrent(value) { this.maxConcurrent = value; return this; } } // 在 downloadFiles 中应用参数 async downloadFiles(repoId, files, targetDir, options = {}) { // 应用并发设置 if (options.maxConcurrent) { this.queue.setMaxConcurrent(options.maxConcurrent); } // ... 其余逻辑 } ``` **影响**: 用户的并发控制配置无效 ### 🟡 中优先级(应该修复) #### 5. 文件列表统计数据不一致 **位置**: `src/core/listing.js:504–527, 346–352` **问题描述**: - `generateStats` 设置 `returned_files` 为所有文件数量 - 但响应实际截断到 `maxFiles` - 统计数据与实际返回不符 **修复方案**: ```javascript // 在 standardList 中 const truncatedFiles = files.slice(0, config.maxFiles); const stats = this.generateStats(files, config); stats.returned_files = truncatedFiles.length; // 修正为实际返回数量 stats.truncated = files.length > config.maxFiles; return { success: true, files: truncatedFiles, stats, truncated: files.length > config.maxFiles }; ``` **影响**: 统计信息误导用户 #### 6. 断点续传错误处理改进 **位置**: `src/core/download.js:403–413` **问题描述**: - 服务器不支持断点续传时删除临时文件 - 没有检查文件是否存在就调用 `fs.unlinkSync` **修复方案**: ```javascript // 当前代码 if (headers.Range && response.status !== 206) { logger.warn('服务器不支持断点续传,重新下载'); task.downloadedBytes = 0; fs.unlinkSync(tempPath); // 可能抛出ENOENT错误 } // 修复方案 if (headers.Range && response.status !== 206) { logger.warn('服务器不支持断点续传,重新下载'); task.downloadedBytes = 0; fs.rmSync(tempPath, { force: true }); // force选项避免文件不存在的错误 } ``` **影响**: 错误处理不够健壮 #### 7. Token 占位符可能掩盖认证问题 **位置**: `bin/cli.js:13–17` **问题描述**: - 设置默认的 `'default_token_placeholder'` 可能导致混淆 - 产生"认证存在但无效"的错误信息 **修复方案**: ```javascript // 当前代码 if (!process.env.HUGGINGFACE_TOKEN && !process.env.HF_TOKEN) { process.env.HUGGINGFACE_TOKEN = 'default_token_placeholder'; } // 修复方案:移除占位符,让系统明确报告缺少token if (!process.env.HUGGINGFACE_TOKEN && !process.env.HF_TOKEN) { // 不设置占位符,让验证逻辑明确提示用户配置token } ``` **影响**: 用户体验混淆 #### 6. 测试覆盖关键问题 **问题描述**: - 缺乏对关键逻辑错误的测试覆盖 - 建议添加针对性测试 **修复方案**: 添加以下测试用例: - 批量请求并发控制测试 - 强制重新下载标志测试 - 最大并发数配置测试 - JSON-RPC 错误ID处理测试 - 统计数据一致性测试 **影响**: 质量保证不足 ## 实施计划 ### 阶段一:关键修复(1-2天) - 修复JSON-RPC协议合规性问题 - 解决HTTP并发控制缺陷 - 统一强制下载标志处理 - 实现动态并发参数设置 ### 阶段二:质量改进(1-2天) - 完善统计数据一致性 - 改进错误处理健壮性 - 移除问题性的token占位符 - 添加针对性测试用例 ### 阶段三:测试和验证(1天) - 执行回归测试 - 性能基准测试 ## 风险评估 ### 高风险变更 - HTTP并发控制逻辑修改 - 需要充分测试 - JSON-RPC协议处理变更 - 影响客户端兼容性 ### 中风险变更 - 下载逻辑参数处理 - 可能影响现有用户配置 - 错误处理流程修改 - 需要验证各种异常场景 ### 低风险变更 - 统计数据修正 - 仅影响显示,不影响功能 - 代码风格修复 - 基本无风险 ## 验证标准 ### 功能验证 - [ ] JSON-RPC错误响应符合规范 - [ ] 并发控制正确工作 - [ ] 强制下载功能生效 - [ ] 用户配置的并发数被采用 - [ ] 统计数据准确反映实际情况 ### 兼容性验证 - [ ] Claude Code客户端正常工作 - [ ] API响应格式保持一致 ### 安全验证 - [ ] 路径遍历攻击防护有效 - [ ] 认证错误提示清晰 ## 测试策略 ### 单元测试 - 每个修复项目对应的单元测试 - 边缘情况覆盖 ### 集成测试 - 完整下载流程测试 - MCP协议通信测试 - 并发场景压力测试 ### 回归测试 - 确保现有功能不受影响 - 性能基线对比 --- **注意**: 本优化方案基于代码静态分析,实施时需要结合实际测试结果进行调整。重点关注核心功能的正确性和协议合规性,不考虑向后兼容性约束。

Latest Blog Posts

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/freefish1218/mcp-huggingfetch'

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