[Bug] stop_event() 状态被 clear_result() 重置，导致有回复的过滤插件无法阻断后续 handler

[lingyun14beta]

What happened / 发生了什么

此问题是 #7898 的延伸。#7898 修复了 star_request.py 循环缺少 is_stopped()
检查的问题，但在插件有 yield（发送回复）的场景下，修复仍然失效。

原因：respond/stage.py 发送完消息后会调用 event.clear_result() 将 _result
置为 None，而 is_stopped() 完全依赖 _result，clear_result() 之后
is_stopped() 返回 False，star_request.py 循环顶部的检查失效，后续所有
handler 继续执行。

没有 yield 的插件（如 blacklist）不受影响，因为不触发 respond/stage.py，
_result 不会被清除，导致该 bug 非常隐蔽。

Reproduce / 如何复现？

1. 编写 priority=1 的过滤插件：

   @filter.event_message_type(filter.EventMessageType.ALL, priority=1)
   async def block(self, event: AstrMessageEvent):
   if should_block(event):
   yield event.plain_result("你被拦截了")
   event.stop_event()
   return

2. 开启 DEBUG 日志，触发该插件

3. 观察日志：respond/stage.py 发送回复后，后续 handler 仍然被调用

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

v4.23.6 / Windows 服务器 / QQ 个人号

OS

Windows

Logs / 报错日志

[method.star_request:46]: plugin -> astrbot_plugin_temp_block - intercept_temp_message
（stop_event() 在此调用，yield 触发消息发送）
[respond.stage:183]: Prepare to send - 请勿通过临时会话联系我
（respond/stage.py 发送后调用 clear_result()，is_stopped() 被重置为 False）
[method.star_request:46]: plugin -> astrbot_plugin_keywords_reply - on_message
[method.star_request:46]: plugin -> builtin_commands - help
（后续所有 handler 继续执行，stop_event() 完全失效）

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。

[lingyun14beta]

@dosubot

[dosubot]

感谢详细的 bug 报告！这个分析非常准确。

问题确认： is_stopped() 完全依赖 _result 属性 [1]，而 clear_result() 会将 _result 置为 None [2]，导致 is_stopped() 返回 False。在 onion model 管道中，当插件 yield 消息时，RespondStage 发送消息后会调用 clear_result() [3]，此时控制权返回插件才调用 stop_event()。

不过根据当前代码 [4] [5]，handler 循环已经在 handler 执行完成后、clear_result() 之前 检查 is_stopped()：

for handler in activated_handlers:
    if event.is_stopped():
        break
    wrapper = call_handler(event, handler.handler, **params)
    async for ret in wrapper:
        yield ret
    if event.is_stopped():   # ← 在 clear_result() 之前检查
        break
    event.clear_result()

这意味着 yield → respond → clear_result() → 返回插件 → stop_event() → handler结束 → is_stopped()检查 这个流程中，stop_event() 是在 clear_result() 之后重新设置的，而 is_stopped() 检查在 clear_result() 之前执行，所以理论上当前修复应该能正确工作。

但你说得对，这里存在架构耦合风险。 stop_event() 和 is_stopped() 都依赖 _result [6]，这种设计很脆弱。推荐的改进方案是引入独立的 _stopped 标志：

class AstrMessageEvent:
    def __init__(self):
        self._stopped: bool = False  # 独立标志

    def stop_event(self) -> None:
        self._stopped = True
        if self._result is None:
            self.set_result(MessageEventResult().stop_event())
        else:
            self._result.stop_event()

    def is_stopped(self) -> bool:
        return self._stopped  # 不再依赖 _result

    def clear_result(self) -> None:
        self._result = None
        # _stopped 不受影响

这样 clear_result() 永远不会影响 stopped 状态，彻底消除耦合问题。

你愿意提交 PR 的话，建议同时做这个解耦改动，这样更稳健。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[lingyun14beta]

@dosu PR #7900 的检查位置是： async for ret in wrapper: yield ret if event.is_stopped(): break event.clear_result() yield 触发 respond/stage.py 发送消息，发送完毕后 respond/stage.py 调用 clear_result() 将 _result 置为 None，此时控制权才回到 if event.is_stopped() 的检查。由于 is_stopped() 完全依赖 _result，clear_result() 之后检查结果为 False，break 不会触发，后续 handler 继续执行。 因此 在这里我认为_force_stopped 标志是必要的补充。

[dosubot]

你说得对，我之前的分析有误，重新梳理一下实际执行顺序：

当插件执行 yield event.plain_result("被拦截了") 然后 event.stop_event() 时：

1. 插件 yield → call_handler 设置 _result 并 yield
2. star_request.py 第 50 行 yield ret → 控制权传递到下游管道
3. RespondStage 发送消息后调用 clear_result()，_result 被置为 None [1]
4. 控制权返回插件，插件继续执行 stop_event() → 重新设置 _result 为 STOP
5. handler 结束 → 第 51 行 if event.is_stopped(): break 检查

所以在这个流程中，stop_event() 在 clear_result() 之后执行，is_stopped() 在检查时应该返回 True。

但你提到的担忧是完全合理的——这个正确性依赖于 stop_event() 必须在最后一个 yield 之后调用。如果插件的写法是：

event.stop_event()
yield event.plain_result("被拦截了")  # yield 触发 clear_result()，覆盖掉 stop 状态

那 stop_event() 就会被 clear_result() 吞掉，is_stopped() 返回 False [2]。

这种对调用顺序的隐式依赖确实很脆弱。引入独立的 _force_stopped 标志是正确的做法——让 clear_result() 永远无法影响 stopped 状态，无论插件以何种顺序调用 yield 和 stop_event() 都能正确工作。

支持你提交 PR 加入 _force_stopped 标志。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[lingyun14beta]

@dosubot 感谢分析！我的插件写法是先 yield 后 stop_event()，符合文档示例。
但实测中 PR #7900 的修复仍然失效，原因似乎是：yield 触发 respond/stage.py
发送消息并调用 clear_result()，控制权返回时 if event.is_stopped() 检查，
此时 _result 已被置为 None，返回 False，break 不触发。
插件随后执行 stop_event() 重新设置 _result，但 async for 已结束，
event.clear_result() 再次清除状态，下一个 handler 执行前状态再次丢失。
因此 _force_stopped 标志仍然是必要的。

[lingyun14beta]

豆包呢😡

[dosubot]

感谢你的耐心纠正，我仔细重新看了代码，你说的是对的。

关键在于 call_handler 的逻辑 [1]：当插件 yield 一个 MessageEventResult 时，wrapper 执行 event.set_result(ret) 后做一个 bare yield（不带值）。这个 bare yield 传播到 star_request.py 的 async for ret in wrapper: yield ret [2]，触发下游管道（RespondStage 发送消息 + clear_result()）。

然后控制权回到 call_handler 的 async for，继续迭代插件 handler，插件执行 stop_event()，之后 return。 call_handler 的 async for 结束，但此时 call_handler 自身不再 yield，所以 star_request.py 的 async for ret in wrapper 循环也结束了。

到达第 51 行 if event.is_stopped() 时——按理说 stop_event() 已经执行，_result 应该不为 None，is_stopped() 应该返回 True…

但问题在于： 如果插件的 stop_event() 和 return 之间没有再次 yield，那 stop_event() 的效果确实应该保留到第 51 行的检查。你实测中仍然失效的话，可能需要确认一个细节：你的插件在 stop_event() 之后是否还有其他 yield 或者 return 之前是否触发了其他代码路径？

不过，无论实际原因如何，你的核心论点完全成立：将 stopped 状态耦合在 _result 上是脆弱的架构设计。_result 在管道中被频繁 set/clear，任何意外的 clear_result() 调用都会悄悄吞掉 stopped 状态。引入独立的 _force_stopped 标志是正确的解耦方案——让 stopped 语义不再依赖 _result 的生命周期，使 stop_event() 在任何调用时机下都可靠工作。

支持你提交 PR 🙌

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.