【Bug已解决】Codex App: new task creation times out when configured MCP server is unreachable 解决方案原始报错线索Codex App: new task creation times out when configured MCP server is unreachable当用户配置的某个 MCP 服务器连不上时创建新任务会一直超时整个创建流程被拖死。一、现象长什么样用户配了一个 MCP 服务器可能是公司内网、可能暂时宕机。然后点「新建任务」界面转圈几秒/几十秒后报「创建超时」创建任务本身根本不需要这个 MCP 服务器——它只是「锦上添花」的扩展能力但只要 MCP 不可达创建就必超时把 MCP 配置删掉创建立刻恢复正常。 根因是**「可选依赖」被当成了「必需依赖」且没设超时隔离主流程被一个无关紧要的服务拖死**。二、背景必需依赖 vs 可选依赖任何创建流程都依赖一些东西必需依赖数据库、鉴权服务——它们挂了创建确实该失败可选依赖MCP 服务器、插件后端、推荐服务——它们挂了创建仍应成功只是少了增强能力。 把可选依赖当成必需是「创建被拖死」的根源。此外即使依赖必需也要有超时隔离不能让一个慢依赖无限阻塞主流程。三、为什么创建超时根因3.1 可选依赖同步阻塞主流程创建任务时代码里mcp.fetch_tools()是同步调用没设超时MCP 不可达就一直等 TCP 超时常达数十秒。3.2 没区分必需 / 可选MCP 挂了代码把它当致命错误整个创建 abort而非「跳过增强、继续创建」。3.3 重试放大超时对不可达的 MCP 还做多次重试每次都等满超时总耗时叠加。3.4 无健康度短路没在创建前先快速探活 MCP直接进重逻辑浪费时间。四、最小可运行复现可选依赖阻塞主流程下面演示「MCP 不可达时同步等待」如何拖死创建import time, socket def fetch_mcp_tools_blocking(host, port): # 错误无超时连接不可达时等系统 TCP 超时默认可长达几十秒 s socket.create_connection((host, port)) # 阻塞直到超时 return s def create_task_bad(task): tools fetch_mcp_tools_blocking(192.168.99.99, 9999) # 不可达 return {task: task, tools: tools} if __name__ __main__: t0 time.time() try: create_task_bad({name: x}) except Exception as e: print(f创建失败({time.time()-t0:.1f}s): {e}) # 数十秒后才失败不可达的 MCP 让创建卡几十秒才失败——核心功能被可选依赖拖垮。五、解决方案一所有外部依赖调用必须设超时把无超时的阻塞调用改成「短超时 快速失败」import socket def fetch_mcp_tools(host, port, timeout2.0): 带超时的依赖探测不可达就快速失败。 s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) try: s.connect((host, port)) return [tool_a, tool_b] # 示意 except (socket.timeout, OSError): return None # 不可达 finally: s.close() if __name__ __main__: import time t0 time.time() tools fetch_mcp_tools(192.168.99.99, 9999, timeout2.0) print(f探测耗时 {time.time()-t0:.1f}s, 工具{tools}) # 2s 内返回 None2 秒超时不可达立刻返回None不再拖几十秒。六、解决方案二区分必需 / 可选可选失败降级创建主流程把 MCP 当可选不可达就跳过增强任务照常创建def create_task(task, mcp_endpointNone): 创建任务MCP 是可选的不可达则降级创建。 task_id ftask-{int(time.time())} enhancement None if mcp_endpoint: tools fetch_mcp_tools(*mcp_endpoint, timeout2.0) if tools is None: # 可选依赖不可用 - 降级不阻塞创建 enhancement skipped:mcp_unreachable else: enhancement tools return {task_id: task_id, task: task, enhancement: enhancement} if __name__ __main__: # MCP 不可达但任务照样建出来 result create_task({name: x}, mcp_endpoint(192.168.99.99, 9999)) print(result) # enhancementskipped:mcp_unreachable创建成功可选依赖失败只影响「增强部分」核心创建不受影响解决 3.2。七、解决方案三健康度短路 不重试不可达创建前先快速探活不可达直接跳过且对「连接级不可达」不做重试重试只用于「瞬时限流」def maybe_enhance(mcp_endpoint): 只对『可达』的 MCP 做增强不可达立即放弃不重试。 if mcp_endpoint is None: return None # 探活连接级失败不重试重试对『主机不可达』无意义只会叠加超时 tools fetch_mcp_tools(*mcp_endpoint, timeout1.5) if tools is None: return skipped # 不重试直接降级 return tools def create_task_v2(task, mcp_endpointNone): enhanced maybe_enhance(mcp_endpoint) return {task_id: ftask-{int(time.time())}, enhanced: enhanced} if __name__ __main__: print(create_task_v2({name: x}, (192.168.99.99, 9999)))连接不可达是「确定性失败」重试只会叠加超时——直接降级最合理解决 3.3。八、解决方案四把依赖增强异步化更彻底的做法创建任务先返回不含 MCP 增强MCP 增强在后台补充import threading def create_task_async(task, mcp_endpointNone): task_id ftask-{int(time.time())} # 主流程立即返回MCP 增强后台做 def background_enhance(): if mcp_endpoint: tools fetch_mcp_tools(*mcp_endpoint, timeout2.0) # 拿到后写入任务元数据示意 print(f[{task_id}] 后台增强: {tools}) threading.Thread(targetbackground_enhance, daemonTrue).start() return {task_id: task_id, status: created} if __name__ __main__: r create_task_async({name: x}, (192.168.99.99, 9999)) print(任务已创建(不等 MCP):, r) # 立即返回创建永远不被 MCP 阻塞——MCP 只是「后续补充」彻底解耦。九、排查清单「依赖不可达时创建超时」按下面排查依赖是必需还是可选MCP 类增强应可选第六节外部调用有超时吗无超时阻塞是元凶可选失败是否降级还是 abort 整个创建第六节是否对『不可达』做无意义重试连接级失败应直接降级第七节能否异步化增强创建先返回、增强后台补第八节健康度能否短路创建前先探活第七节超时设置合理吗2 秒级而非数十秒第五节日志是否记录『MCP 跳过原因』。十、小结「依赖的 MCP 不可达时新任务创建超时」的根因是可选依赖被当成必需依赖且无超时隔离主流程被一个无关服务阻塞至超时。通用修复必设超时所有外部依赖调用短超时2s 级不可达快速失败区分必需/可选可选依赖MCP不可达则降级创建核心功能不受影响第六节不重试不可达连接级失败确定性直接降级而非叠加超时第七节异步解耦创建先返回增强后台补充彻底不被阻塞。 一句话创建资源的主流程绝不能被『可选增强依赖』阻塞外部调用一律短超时可选失败一律降级确定性不可达一律不重试。把核心路径和增强依赖解耦应用才能在「配置了个暂时宕机的 MCP」时依然秒级创建任务——这与第 129 篇连接韧性、第 130 篇后台压缩、第 117 篇 SSH 保活共同体现「外部依赖必须超时隔离、可选降级」。