变更摘要

本 PR 主要修复会话运行时热更新（update_config）过程中新旧 ServiceManager 可能并存、以及旧 ServiceManager 清理失败时静默泄漏的问题，从而杜绝孤儿 Pod / 重复扩容。核心改动是将整个热更新切换流程（包括等待旧 SM 销毁）纳入 _update_lock 串行化保护，新增 _old_sm_cleanup_task 字段记录上一次清理任务并在下次热更新前等待其完成，同时修复了重复创建清理任务的问题，并在重试仍无法空闲清理时强制调用旧 SM 的 stop() 释放其持有的 Pod。

主要改动

• 热更新全流程串行化: Access.update_config 将创建、启动新 SM 以及引用切换全部放入 _update_lock 临界区，并在切换前等待上一次旧 SM 的清理任务完成，禁止新旧 SM 并存与并发热更新。
• 单次清理任务 + 任务跟踪: 新增 _old_sm_cleanup_task 字段保存旧 SM 的后台清理任务，移除原先重复的两处 asyncio.create_task 调用，改为只创建一个任务并记录，供下次热更新前 await。
• 旧 SM 超时强制停止: _graceful_stop_old_service_manager 在达到 max_retries 仍无法按空闲清理时，不再仅打日志返回，而是调用 await old_sm.stop() 强制停止并释放其 Pod，避免 ServiceManager 与 Pod 泄漏。
• 新增回归测试: test_access_hotreload.py 增加两个测试用例，分别验证旧 SM 销毁未完成时第二次热更新会被阻塞等待、每次只起一个清理任务，以及旧 SM 始终 busy 时超次数后会被强制 stop。

代码审查

✅ 未发现问题

欢迎来到 openJiuwen 社区

Hey @wangmingqi , 感谢你对社区的贡献.

机器人使用手册

有关指令的使用，可以点击 此处 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。

AtomGit AI 助手使用指南

在 PR 评论中使用命令即可触发。支持在普通评论和代码行评论中使用。

免责声明

AI 助手可能存在误判，请结合自身判断。可以对评论点 👍 或 👎 帮助我们改进。

CLA 签署成功

wangmingqi, 感谢您的代码贡献。 所有的代码贡献者都已完成了 CLA 签署。 👍