环境
- Windows 11
- Chrome Extension v2.0.9
- Wechatsync CLI v1.1.0
- 默认桥接端口:9527 / 9528
问题描述
当旧的 Wechatsync Primary 进程仍占用 9527/9528,但 Chrome 扩展已经断开时,新的 CLI 会进入 Secondary 模式。此时 GET /status 仍返回 HTTP 200 和 connected: false,Secondary 因为认为 Primary “可达”而不会尝试接管,只会一直等待到连接超时。
最终提示“已有实例正在运行但 Chrome Extension 未连接”,但用户无法判断具体是哪个旧进程占用了端口,也无法区分旧实例、扩展开关关闭和 Token 不一致。
复现步骤
- 启动一次 CLI/MCP Bridge,使其成为 Primary。
- 让 Chrome 扩展断开桥接,但保留旧 Node 进程以及 9527/9528 监听。
- 再次执行任意 CLI 命令,例如
wechatsync platforms --auth。
- 新进程进入 Secondary 模式,并等待到超时。
可观察到:
{"connected":false,"mode":"primary"}
实际结果
- 新 CLI 无法接管。
- 等待到超时后只给出通用的扩展/Token 提示。
- 终止旧 Node 进程并重新启动 Bridge 后,连接立即恢复。
预期结果
/status 应返回 PID、启动时间或实例 ID,帮助识别当前 Primary。
- CLI 超时时应显示 Primary 的诊断信息。
- 后续可考虑基于 PID/心跳或进程锁提供安全的旧实例重置能力;不建议 Secondary 在无法确认状态时直接强杀 Primary。
建议修复
- 在
/status 增加 pid、startedAt、uptimeMs。
- Secondary 保存 Primary 状态,并在超时提示中显示进程信息。
- Bridge 停止时拒绝并清理所有挂起请求。
- 后续设计
--reset-bridge 或带所有权校验的锁文件/心跳接管方案。
相关修复将通过单独 PR 提交。日志已脱敏,不包含 Token 或账号信息。
环境
问题描述
当旧的 Wechatsync Primary 进程仍占用 9527/9528,但 Chrome 扩展已经断开时,新的 CLI 会进入 Secondary 模式。此时
GET /status仍返回 HTTP 200 和connected: false,Secondary 因为认为 Primary “可达”而不会尝试接管,只会一直等待到连接超时。最终提示“已有实例正在运行但 Chrome Extension 未连接”,但用户无法判断具体是哪个旧进程占用了端口,也无法区分旧实例、扩展开关关闭和 Token 不一致。
复现步骤
wechatsync platforms --auth。可观察到:
{"connected":false,"mode":"primary"}实际结果
预期结果
/status应返回 PID、启动时间或实例 ID,帮助识别当前 Primary。建议修复
/status增加pid、startedAt、uptimeMs。--reset-bridge或带所有权校验的锁文件/心跳接管方案。相关修复将通过单独 PR 提交。日志已脱敏,不包含 Token 或账号信息。