[Bug] 配置热重载时端口冲突导致进程崩溃的问题

[s1othhhhhh]

发生了什么

我在AstrBot的WebUI中的本插件的配置设置中填写UMO并保存时，整个AstrBot就崩溃了。
我把日志给deepseek看了，然后验证了一下。可能的原因是Proactive Chat 插件在初始化时会启动一个内部 Web 服务器跑在 127.0.0.1:4100，当在主面板(http://127.0.0.1:6185)保存配置时，AstrBot 会发一个"配置已变更"的通知给插件。插件收到后尝试重启自己的 Web 服务器，但它没有先停掉旧的，直接起新的 → 两个进程抢 4100 端口 → uvicorn 内部调了 sys.exit(1) → 整个 AstrBot 被拉倒。

如何复现？

1.打开AstrBot WebUI
2.在AstrBot插件中找到主动消息并打开插件配置
3.更改配置后点击保存并退出

插件版本

v1.2.4

AstrBot 版本

v4.25.2

部署方式

AstrBot App 桌面应用部署

使用的消息平台适配器

QQ 官方机器人 (Websockets 方式)

其他平台名称（如选择“其他平台”请填写）

No response

操作系统

Windows

补充说明（可选）

No response

报错日志

[20:54:26.504] [Core] [ERRO] [v4.25.2] [star.star_manager:1245]: ----- 插件 astrbot_plugin_proactive_chat 载入失败 -----

[20:54:26.509] [Core] [ERRO] [v4.25.2] [star.star_manager:1248]: | Traceback (most recent call last):
| File "E:\ProgramFiles\AstrBot\backend\python\Lib\site-packages\uvicorn\server.py", line 172, in startup
| server = await loop.create_server(
| File "E:\ProgramFiles\AstrBot\backend\python\Lib\asyncio\base_events.py", line 1584, in create_server
| raise OSError(err.errno, msg) from None
| OSError: [Errno 10048] error while attempting to bind on address ('127.0.0.1', 4100): [winerror 10048] 通常每个套接字地址(协议/网络地址/端口)只允许使用一次。

| During handling of the above exception, another exception occurred:

| Traceback (most recent call last):
| File "E:\ProgramFiles\AstrBot\backend\python\Lib\asyncio\runners.py", line 195, in run
| return runner.run(main)
| ...
| File "C:\Users\s1oth.astrbot\data\plugins\astrbot_plugin_proactive_chat\core\web_admin_server.py", line 1299, in _serve
| await self.server.serve()
| File "E:\ProgramFiles\AstrBot\backend\python\Lib\site-packages\uvicorn\server.py", line 182, in startup
| sys.exit(1)
| SystemExit: 1

| During handling of the above exception, another exception occurred:

| Traceback (most recent call last):
| File "\?\E:\ProgramFiles\AstrBot\backend\app\astrbot\core\star\star_manager.py", line 1229, in load
| await metadata.star_cls.initialize()
| File "C:\Users\s1oth.astrbot\data\plugins\astrbot_plugin_proactive_chat\core\plugin_lifecycle.py", line 138, in initialize
| await self.web_admin_server.start()
| File "C:\Users\s1oth.astrbot\data\plugins\astrbot_plugin_proactive_chat\core\web_admin_server.py", line 1324, in start
| await asyncio.sleep(0.1)
| asyncio.exceptions.CancelledError

你愿意提交 PR 吗？

• 是的，我愿意提交 PR!

Code of Conduct

• 我已阅读并同意遵守该项目的 行为准则。

[dosubot]

Hi @s1othhhhhh! I'm Dosu and I'm helping the Pancake Labs team.

我查看了相关代码，你的分析方向是对的——端口冲突确实是崩溃原因。不过根据代码结构来看，插件其实有正确的关闭逻辑：

• terminate() 方法会调用 self.web_admin.stop() 来关闭旧服务器 [1]
• stop() 方法通过设置 self.server.should_exit = True 触发 Uvicorn 优雅关闭，并等待最多 5 秒 [2]
• AstrBot 的重载机制也按正确顺序执行：terminate → unbind → load → initialize [3]

所以问题更可能是异步时序竞争（race condition）：stop() 设置了 should_exit = True 并等待最多 5 秒，但 Uvicorn 在 Windows 上可能没有在这个时间窗口内完全释放端口，导致新的 start() 绑定时旧端口仍被占用。另一种可能是在 terminate 过程中某步骤抛出异常，导致 web_admin.stop() 没有被执行到（虽然代码有 try-except 保护）。

建议的修复方向：

1. 在 stop() 中，除了设置 should_exit = True，还应显式关闭底层 socket 以确保端口立即释放
2. 在 start() 之前增加端口可用性检查，如果端口仍被占用则等待重试
3. 增加 terminate 和 start 阶段的日志输出，方便定位是否 stop() 真的被调用了

作为临时解决方案，保存配置后如果崩溃了，重启 AstrBot 即可恢复正常。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[DBJD-CR]

@dosu 你帮我看看我那个灾害预警的插件是不是也存在此类问题的风险。

[dosubot]

@DBJD-CR 我看了一下 astrbot_plugin_live_dashboard 的代码，不存在此类端口冲突的风险。

原因很简单：这个插件没有启动任何 Web 服务器，也不绑定任何端口 [1]。它只是一个纯 HTTP 客户端，通过 httpx 向外部 Live Dashboard 服务发出请求 [2]，不像 proactive_chat 那样内嵌了一个 Uvicorn 服务。

另外，它的 terminate() 方法也正确实现了资源清理——会调用 await self.dashboard_service.close() 关闭 httpx 客户端 [3]，并且有异常处理保护。

所以配置热重载时不会出现"两个进程抢端口"的问题，这类 bug 只会影响有内嵌服务器的插件。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[DBJD-CR]

@dosu 是 astrbot_plugin_disaster_warning 不是 live_dashboard

[dosubot]

@DBJD-CR 抱歉搞混了！astrbot_plugin_disaster_warning 这个仓库没有被索引到我的数据源中，我无法直接查看它的代码。

如果你想让我帮你分析，可以：

1. 将 astrbot_plugin_disaster_warning 仓库添加到我的数据源中，我就能直接检查
2. 或者你可以告诉我：这个插件有没有像 proactive_chat 一样内嵌 Web 服务器（比如用 uvicorn/FastAPI 绑定端口）？如果有的话，就需要关注同样的风险；如果只是纯 HTTP 客户端（向外请求 API 获取预警信息），则不存在这类问题

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[DBJD-CR]

@dosu 我重新配置了一下，你看看好了没

[dosubot]

@DBJD-CR 好了！这次能看到 astrbot_plugin_disaster_warning 的代码了。

分析结果：风险较低，但不是完全没有。

这个插件确实也启动了一个 FastAPI/Uvicorn Web 服务器（默认 0.0.0.0:8089）[1]，但它的生命周期管理比 proactive_chat 做得更好：

✅ 已有的保护措施：

• terminate() 中显式调用了 Web 服务器关闭逻辑 [2]
• 设置 should_exit = True 通知 Uvicorn 退出
• 有 5 秒超时，超时后强制 cancel task [3]
• 关闭前先清理 WebSocket 连接和后台任务
• 资源清理有明确的顺序，Web 服务器最后关闭 [4]

⚠️ 残余风险（和 proactive_chat 一样的问题）：

• 同样依赖 5 秒超时 + should_exit 信号，如果 Uvicorn 在 Windows 上没有及时释放端口，理论上新实例仍可能绑定失败
• 如果 AstrBot 框架在极端情况下没有正确调用 terminate() 就直接重新 initialize()，也会冲突

总体来说，灾害预警插件的实现是正确的，和 proactive_chat 用的是相同的 shutdown 模式（should_exit = True + 5秒等待）。如果 proactive_chat 的问题最终确认是这个模式本身在 Windows 上不够可靠，那灾害预警插件也需要同步修复。但目前来看，灾害预警插件的生命周期管理没有明显的遗漏。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Ayleovelle]

尝试修复中