socket.io Manager reconnection is unbounded after a server-disconnect retry fails at the transport level

问题场景

在 InvokeAI Web 前端中，socket.io 客户端与后端建立连接。此前 #9540 为“服务器主动断开”（io server disconnect）增加了有上限的重试：客户端最多执行 5 次 socket.connect()，采用倍增延迟，上限由 MAX_SERVER_DISCONNECT_RECONNECTS 控制。但该上限只约束服务器主动断开路径。当自定义重试过程中某次连接在传输层失败（后端未运行、端口拒绝连接等），socket.io Manager 会接管重连，并按默认配置无限重试。Issue 作者指出，这不是 #9540 引入的新行为，普通网络中断本来也会触发；新增的是“有上限路径可以交接给无上限路径”这一交互。

报错原文

socket.io Manager reconnection is unbounded after a server-disconnect retry fails at the transport level

socket.connect() calls Manager.open(), which resets skipReconnect = false, and the socket's options set neither reconnection nor reconnectionAttempts — so the manager's own defaults apply: reconnection: true, reconnectionAttempts: Infinity, reconnectionDelay: 1000, reconnectionDelayMax: 5000, randomizationFactor: 0.5 (socket.io-client/build/esm/manager.js:21-29). If one of our retry attempts fails at the transport level — server down, port refused — the manager takes over and retries indefinitely. Our counter never advances, because a failed attempt emits connect_error, not disconnect.

原因分析

根本原因是 socket.io 的 Manager 默认配置为无限重连。自定义的 5 次上限仅针对服务器主动断开，在那一路径中 skipReconnect 会阻止 Manager 自动重连，由客户端自行驱动 socket.connect()。但 socket.connect() 会调用 Manager.open()，把 skipReconnect 重置为 false；同时 socket 选项未设置 reconnection 和 reconnectionAttempts，于是回落到 Manager 默认值（无限重连、1s 起始延迟、5s 最大延迟、随机抖动）。若自定义重连中某次尝试在传输层失败，会触发 connect_error 而非 disconnect，自定义计数器不会推进，Manager 随即接管并无限重试。

Issue 中一位评论者使用 socket.io-client 4.8.3、engine.io-client 6.6.4、socket.io 4.8.3 搭建本地复现环境，观察到 Manager 重试间隔约为 2.04s、4.04s、5.02–5.04s，并且在监听器恢复后第 7 次尝试成功重连，使用的是 auth 回调提供的最新值；该次运行未复现“180ms 内四次重连”的突发。因此原 Issue 中关于突发节奏的观察在锁定版本下未能稳定复现，但无上限重连本身得到确认。

环境排查

• 确认 socket.io-client 版本：Issue 中验证为 4.8.3。
• 确认 engine.io-client 版本：Issue 中验证为 6.6.4。
• 确认 socket.io 服务端版本：Issue 中验证为 4.8.3。
• 确认 InvokeAI 前端事件处理代码是否为 invokeai/frontend/web/src/services/events/useSocketIO.ts，以及是否包含 MAX_SERVER_DISCONNECT_RECONNECTS。
• 确认后端服务是否可达：检查端口是否拒绝连接、进程是否运行、代理是否中断。
• 浏览器开发者工具中观察 socket.io 的 connect_error、reconnect_attempt、disconnect 事件频率，判断是自定义重试还是 Manager 接管。
• Issue 未提供 Python、PyTorch、CUDA、显卡或操作系统信息，无需据此排查。

解决步骤

1. 先确认后端 InvokeAI 服务是否正常运行、端口是否可访问。若后端不可达，恢复后端即可让 socket 重新连接，这属于 Manager 的自愈路径。
2. 确认现象是否只发生在服务器主动断开之后的重试阶段：在浏览器控制台观察断开来源是 io server disconnect 还是普通网络中断。
3. 如果目标是让有上限的服务器主动断开重试与 Manager 重连的边界更清晰，可优先尝试采用 Issue 最终方案：保留 Manager 恢复路径不变，仅在 MAX_SERVER_DISCONNECT_RECONNECTS 处补充说明其作用范围，并增加测试覆盖（自定义重试期间出现 connect_error 时由 Manager 接管、不额外增加第二个重连驱动；socket 构建时 Manager 重连保持无上限）。
4. 不要通过设置 socket.io.opts.reconnection = false 或全局限制 reconnectionAttempts 来消除该现象，这会造成标签页在短暂后端不可用后永久失去事件。
5. 如确实需要限速失败路径，应作为独立变更处理，明确最小重试间隔、最大值、抖动、退避重置时机、恢复后是否还原临时策略，并同时测试“拒绝连接的端口”和“黑洞式不可达主机”两种场景。

验证方法

在浏览器开发者工具中观察：服务器主动断开后，自定义重连计数在达到上限前推进；若自定义重连出现 connect_error，Manager 接管重连且不产生第二个并行的重连驱动。恢复后端或监听器后，socket 能在不使用页面刷新、且使用 auth 回调最新值的情况下重新连接。Issue 评论者的本地测试还验证了：显式断开时能取消正在进行的 Manager 重试循环，以及仅调大 reconnectionDelayMax 不会改变最初的 1s / 2s / 4s 退避。

参考来源

invoke-ai/InvokeAI #9542

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。