[Bug] Telegram 私聊流式输出失败：sendMessageDraft Text must be non-empty

[yancj9ya]

What happened / 发生了什么

在 Astrbot v4.22.2 中，开启流式输出后，Telegram 私聊会持续触发以下错误：
[Telegram] sendMessageDraft 失败: Text must be non-empty
日志中 _draft_sender_loop 每 0.5 秒尝试发送一次空文本，导致连续 WARN。
网页测试对话的流式输出完全正常，问题仅出现在 Telegram 私聊场景。

Reproduce / 如何复现？

📚 如何复现 / How to reproduce

1. Astrbot 版本：v4.22.2（已包含 PR feat(telegram): supports sendMessageDraft API #5726）
2. AI 配置 → 其他配置 → 流式输出 开启
3. Telegram 机器人私聊任意消息
4. 观察日志，立即出现连续 sendMessageDraft 失败: Text must be non-empty

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

📚 环境信息 / Environment

⦁ Astrbot 版本：v4.22.2
⦁ python-telegram-bot 版本：22.7（已满足 ≥22.6 要求）
⦁ 平台：Telegram（私聊）
⦁ LLM 流式：网页测试正常（排除 LLM 侧问题）
⦁ 部署方式：（请在此补充你的部署方式，例如 Docker / 直接运行 / Windows 等）

📚 预期行为 / Expected behavior

私聊应正常使用 sendMessageDraft 实现打字机效果，不出现空文本错误，流式输出顺畅。

📚 实际行为 / Actual behavior

私聊时 _draft_sender_loop 在 LLM 第一个 token 到达前就发送了空 text，触发 Telegram API 强制校验失败，流式输出整体中断（群聊不受影响，仍正常）。

OS

Windows

Logs / 报错日志

[2026-04-04 17:58:03.457] [Core] [INFO] [respond.stage:200]: 应用流式输出(telegram)
[2026-04-04 17:58:03.457] [Core] [INFO] [telegram.tg_event:513]: [Telegram] 流式输出: 使用 sendMessageDraft (私聊)
[2026-04-04 17:58:04.251] [Core] [WARN] [v4.22.2] [telegram.tg_event:409]: [Telegram] sendMessageDraft 失败: Text must be non-empty
...（后续每 0.5 秒重复出现多次）
📚 补充说明

⦁ 该问题出现在 PR #5726（2026-03-03 引入 sendMessageDraft）之后。
⦁ Telegram Bot API 本身无额外版本要求，python-telegram-bot 已更新到最新。
⦁ 临时关闭“流式输出”开关可立即规避，但希望官方能加强 _draft_sender_loop 对初始空缓冲区的判断逻辑。

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 @yancj9ya! I'm Dosu and I’m helping the AstrBot team.

看了一下当前代码中 _draft_sender_loop 的实现 [1]，逻辑上有两层防护：

1. 事件驱动：循环通过 text_changed.wait() 阻塞，只有 _append_text 被调用（即收到 token）时才唤醒
2. 空文本检查：第 556 行 if delta and delta != last_sent_text: 确保 delta 非空才发送

理论上在第一个 token 到达前不应该发送空文本。

但有一个可能的竞态场景：在 finally 块中（第 617-619 行），当 generator 结束或抛异常时会执行 done = True; text_changed.set() 来唤醒循环退出 [2]。如果 LLM 返回的第一个 chain 不包含 Plain 文本（例如只有非文本组件），或者 generator 在产出第一个文本 token 前就因为某种原因触发了 text_changed.set()，delta 仍为空字符串 ""，此时第 556 行的检查 if delta 是 False，不会进入发送——但循环会退出。

另一个更可能的原因：检查一下你的 LLM 提供商是否在真正的文本 token 之前先发送了空字符串 token。如果 _append_text("") 被调用，delta 仍然是 ""，text_changed 会被 set，循环被唤醒后 if delta 为 False 不会发送——理论上也不应该触发错误。

不过从你的日志看 "每 0.5 秒重复出现多次"，这更像是旧版代码基于定时轮询（interval-based）的行为而非当前信号驱动的实现。请确认：

1. 你运行的代码是否确实是最新的 v4.22.2？ 可以检查 tg_event.py 中 _draft_sender_loop 是否包含 await text_changed.wait()（信号驱动），还是 await asyncio.sleep(0.5)（定时轮询）。如果是后者，说明代码没有更新到最新版本。
2. 如果确认是最新代码，可以尝试在 _send_message_draft 方法中添加空文本检查作为额外防护 [3]：

async def _send_message_draft(self, chat_id, draft_id, text, ...):
    if not text:  # 额外防护
        return
    ...

这个改动可以作为临时 workaround，同时也是一个合理的防御性编程实践。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
  

[yancj9ya]

确实是最新的

[dosubot]

感谢确认！既然代码确实是最新版（包含 text_changed.wait() 信号驱动），那问题很可能出在 telegramify_markdown.markdownify() 的返回值上。

看代码第 560-566 行 [1]，delta 非空通过了检查后，markdownify(draft_text) 的返回值 md 被直接传给 _send_message_draft()，没有做空字符串校验。如果第一个 token 是纯空白字符或某些特殊字符（如 Markdown 控制字符），markdownify() 有可能将其转换为空字符串，从而触发 Telegram API 的 "Text must be non-empty" 错误。

建议的修复：在 _draft_sender_loop 中，发送前增加对 md 的非空校验：

md = telegramify_markdown.markdownify(draft_text)
if md:  # 防止 markdownify 返回空字符串
    await self._send_message_draft(
        user_name, draft_id, md,
        message_thread_id, parse_mode="MarkdownV2",
    )
    last_sent_text = draft_text

同样，在 _send_message_draft 方法本身 [2] 也可以加一层防御：

async def _send_message_draft(self, chat_id, draft_id, text, ...):
    if not text or not text.strip():
        return
    ...

这两处改动都很小，如果你愿意提交 PR 的话应该很容易实现。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
  

[yancj9ya]

不是这个bot怎么老想让我提pr

[Sjshi763]

不是这个bot怎么老想让我提pr

毕竟会减轻其他入的工作