[Bug]telegram运行一段时间后无法接收新消息，重启适配器才能使用

[MidoriDaisuki]

What happened / 发生了什么

telegram运行一段时间后无法接收新消息，控制台没有报错，重启适配器才能使用（关闭适配器时报错，重启后立即收到所有消息，但telegram好像长时间没收到的消息会消失qvq），如果没办法修复希望可以添加定时重启适配器（例如一个小时重启一次）的功能qvq

Reproduce / 如何复现？

telegram运行一段时间后

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

4.25.1，windows，telegram

OS

Windows

Logs / 报错日志

重启时的日志[16:53:55.103] [Core] [INFO] [platform.manager:269]: 正在尝试终止 telegram 平台适配器 ...
Error while calling get_updates one more time to mark all fetched updates. Suppressing error to ensure graceful shutdown. When polling for updates is restarted, updates may be fetched again. Please adjust timeouts via ApplicationBuilder or the parameter get_updates_request of Bot.
Traceback (most recent call last):
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_transports\default.py", line 101, in map_httpcore_exceptions
yield
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_transports\default.py", line 394, in handle_async_request
resp = await self._pool.handle_async_request(req)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpcore_async\connection_pool.py", line 256, in handle_async_request
raise exc from None
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpcore_async\connection_pool.py", line 232, in handle_async_request
connection = await pool_request.wait_for_connection(timeout=timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpcore_async\connection_pool.py", line 35, in wait_for_connection
await self._connection_acquired.wait(timeout=timeout)
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpcore_synchronization.py", line 149, in wait
with map_exceptions(anyio_exc_map):
File "C:\PATH\Python312\Lib\contextlib.py", line 158, in exit
self.gen.throw(value)
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpcore_exceptions.py", line 14, in map_exceptions
raise to_exc(exc) from exc
httpcore.PoolTimeout

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\request_httpxrequest.py", line 279, in do_request
res = await self._client.request(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_client.py", line 1540, in request
return await self.send(request, auth=auth, follow_redirects=follow_redirects)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_client.py", line 1629, in send
response = await self._send_handling_auth(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_client.py", line 1657, in _send_handling_auth
response = await self._send_handling_redirects(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_client.py", line 1694, in _send_handling_redirects
response = await self._send_single_request(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_client.py", line 1730, in _send_single_request
response = await transport.handle_async_request(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_transports\default.py", line 393, in handle_async_request
with map_httpcore_exceptions():
File "C:\PATH\Python312\Lib\contextlib.py", line 158, in exit
self.gen.throw(value)
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\httpx_transports\default.py", line 118, in map_httpcore_exceptions
raise mapped_exc(message) from exc
httpx.PoolTimeout

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\ext_updater.py", line 400, in _get_updates_cleanup
await self.bot.get_updates(
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\ext_extbot.py", line 672, in get_updates
updates = await super().get_updates(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram_bot.py", line 4865, in get_updates
await self._post(
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram_bot.py", line 704, in _post
return await self._do_post(
^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\ext_extbot.py", line 370, in _do_post
return await super()._do_post(
^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram_bot.py", line 733, in _do_post
result = await request.post(
^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\request_baserequest.py", line 198, in post
result = await self._request_wrapper(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\request_baserequest.py", line 305, in _request_wrapper
code, payload = await self.do_request(
^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\32582\Desktop\jmbot\AstrBotLauncher-0.1.5.6\AstrBot\venv\Lib\site-packages\telegram\request_httpxrequest.py", line 289, in do_request
raise TimedOut(
telegram.error.TimedOut: Pool timeout: All connections in the connection pool are occupied. Request was not sent to Telegram. Consider adjusting the connection pool size or the pool timeout.
[16:53:56.137] [Core] [INFO] [telegram.tg_adapter:760]: Telegram adapter has been closed.

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

Hi @MidoriDaisuki! I'm Dosu and I’m helping the AstrBot team.

这是一个已知的 httpx.PoolTimeout 连接池耗尽问题，在多个版本中都有出现 [1]。

好消息是：PR #7468（2026-04-12 合并）已经引入了自动恢复机制——当检测到连续 3 次网络错误（60秒内），适配器会自动重建 HTTP 客户端和整个 Telegram Application，无需手动重启 [2]。

你使用的是 v4.25.1，理论上应该已经包含这个修复。建议排查以下几点：

1. 检查是否使用了代理：如果你的网络环境需要代理访问 Telegram API，AstrBot 的全局代理设置不会自动应用到 Telegram 适配器的 httpx 客户端，这可能导致连接长时间挂起直到池耗尽 [3]。
2. 查看更早的日志：在适配器"无法接收消息"之前，日志中是否有 NetworkError 或 Flood control exceeded 等错误？如果没有触发连续错误阈值，自动恢复可能不会启动。
3. 确认 telegram_polling_restart_delay 配置：这个值默认为 5 秒，控制轮询重启间隔 [4]。

从日志来看，你的情况是适配器静默停止接收消息（无报错），直到手动重启才触发 PoolTimeout。这可能意味着 polling loop 卡住了但没有产生 exception 来触发自动恢复逻辑。这可能是一个尚未完全覆盖的边缘情况。

建议你在 issue 中补充：在"无法接收消息"期间，日志中是否有任何输出（哪怕是正常的心跳日志），这有助于开发者判断 polling loop 是否仍在运行还是已经完全停止。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[MidoriDaisuki]

Hi @MidoriDaisuki! I'm Dosu and I’m helping the AstrBot team.

这是一个已知的 httpx.PoolTimeout 连接池耗尽问题，在多个版本中都有出现 [1]。

好消息是：PR #7468（2026-04-12 合并）已经引入了自动恢复机制——当检测到连续 3 次网络错误（60秒内），适配器会自动重建 HTTP 客户端和整个 Telegram Application，无需手动重启 [2]。

你使用的是 v4.25.1，理论上应该已经包含这个修复。建议排查以下几点：

1. 检查是否使用了代理：如果你的网络环境需要代理访问 Telegram API，AstrBot 的全局代理设置不会自动应用到 Telegram 适配器的 httpx 客户端，这可能导致连接长时间挂起直到池耗尽 [3]。
2. 查看更早的日志：在适配器"无法接收消息"之前，日志中是否有 NetworkError 或 Flood control exceeded 等错误？如果没有触发连续错误阈值，自动恢复可能不会启动。
3. 确认 telegram_polling_restart_delay 配置：这个值默认为 5 秒，控制轮询重启间隔 [4]。

从日志来看，你的情况是适配器静默停止接收消息（无报错），直到手动重启才触发 PoolTimeout。这可能意味着 polling loop 卡住了但没有产生 exception 来触发自动恢复逻辑。这可能是一个尚未完全覆盖的边缘情况。

建议你在 issue 中补充：在"无法接收消息"期间，日志中是否有任何输出（哪怕是正常的心跳日志），这有助于开发者判断 polling loop 是否仍在运行还是已经完全停止。

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.

@dosu 这是我关闭适配器之前的日志[11:24:43.164] [Core] [INFO] [core.event_bus:61]: [default] [telegram(telegram)] Midori77777/5386373019: 用户发送的消息[11:24:47.431] [Core] [INFO] [respond.stage:183]: Prepare to send - Midori77777/5386373019: 机器人回复的消息
此后没有任何日志，向机器人发消息没有回应，重启时才出现报错并收到消息

[dosubot]

感谢补充日志！这很关键——说明适配器在成功处理并回复了一条消息之后就静默停止了，updater.running 标志可能仍然为 true，但实际上不再接收新 update。

这与已有的一个问题匹配：流式输出（streaming output）或消息发送失败后，polling loop 会静默退出 [1]。具体来说：

• 当 Telegram 的 edit_message_text（流式输出编辑消息）失败或触发 Flood control 时，异常未被正确捕获，导致 polling loop 静默停止 [2]
• 当前的自动恢复机制（PR fix: Telegram polling recovery after network failures #7468）只监控 NetworkError 类型的异常，无法检测这种"无异常但停止接收"的卡死状态 [3]

你是否开启了流式输出（streaming）？ 如果是的话，建议暂时关闭流式输出作为临时解决方案，看问题是否还会复现。

这确实是当前自动恢复逻辑的一个盲区——缺少心跳/超时检测机制来发现 polling 已经停止但没有抛出异常的情况。你的 issue 对开发者定位这个问题很有帮助。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.