fix(cli): prevent monitor notifications after task_stop

[yiliang114]

What this PR does

Explicit monitor cancellation now uses the existing silent cancellation path because the synchronous tool result already confirms the action. Session notification queues also retain monitor identity long enough to discard a queued running event when that monitor has since been explicitly cancelled. Natural completion and failure notifications remain unchanged.

Why it's needed

Stopping a monitor could emit a cancelled notification and drain an already queued running event after the original tool turn. Both were recorded as notification user messages and could wake the model again, polluting the conversation and consuming another full-history request.

Reviewer Test Plan

How to verify

1. In one-shot stream-json mode, ask the model to start a monitor that repeatedly prints a line, immediately stop the returned monitor task, return STOPPED, and return NOTIFICATION_ACK only if a later task notification arrives.
2. Confirm the model calls both monitor and task stop, returns STOPPED, emits no notification user envelope or monitor task-notification after cancellation, and never returns NOTIFICATION_ACK.
3. Confirm a naturally completed or failed monitor still reaches the existing notification path.

Evidence (Before & After)

Before: the real reproduction recorded a notification user message after cancellation and made an extra model request with 17,395 input tokens, followed by NOTIFICATION_ACK.

After: a real qwen3.6-max-preview run called monitor once and task stop once, then returned only STOPPED. Its 16-line JSONL contained zero notification user records and zero NOTIFICATION_ACK responses, and the monitored process was absent after exit. Final verification session: 41558468-2323-4df8-a3a9-f98dba1b1279.

Automated verification: full lint and typecheck passed; 299 targeted tests passed with one pre-existing skip; the full repository build passed.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

Local development entrypoint in one-shot stream-json mode, safe mode enabled, approval mode yolo, no sandbox, real qwen3.6-max-preview model through an OpenAI-compatible endpoint.

Risk & Scope

• Main risk or tradeoff: queued running events are discarded only when the current registry state is explicitly cancelled, so events that race with natural completion or failure remain deliverable.
• Not validated / out of scope: real interactive TUI behavior and Windows/Linux runtime behavior; those paths are covered by focused unit tests or CI.
• Breaking changes / migration notes: none.

Linked Issues

Resolves #7566

中文说明

本 PR 做了什么

显式取消 monitor 时改用已有的静默取消路径，因为同步工具结果已经确认了取消动作。会话通知队列也会保留 monitor 标识，以便在消费前发现该 monitor 已被显式取消时，丢弃此前排队的 running 事件。自然完成和失败通知保持不变。

为什么需要

停止 monitor 后，系统可能同时发送 cancelled 通知，并在原始工具回合结束后继续消费一个已经排队的 running 事件。两者都会被记录为 notification 用户消息并再次唤醒模型，污染对话记录并额外消耗一次完整历史请求。

Reviewer Test Plan

如何验证

1. 在 one-shot stream-json 模式下，让模型启动一个持续输出文本行的 monitor，立即停止返回的 monitor 任务，然后返回 STOPPED；仅当稍后收到任务通知时才返回 NOTIFICATION_ACK。
2. 确认模型实际调用 monitor 和 task stop，返回 STOPPED，取消后不输出 notification 用户 envelope 或 monitor task-notification，也不返回 NOTIFICATION_ACK。
3. 确认自然完成或失败的 monitor 仍会进入现有通知路径。

Before & After 证据

修复前：真实复现会在取消后记录一条 notification 用户消息，并额外发起一次包含 17,395 个输入 token 的模型请求，随后返回 NOTIFICATION_ACK。

修复后：真实 qwen3.6-max-preview 调用分别执行了一次 monitor 和 task stop，最终只返回 STOPPED。对应 16 行 JSONL 中 notification 用户记录为 0，NOTIFICATION_ACK 为 0，退出后没有残留的 monitor 进程。最终验证会话：41558468-2323-4df8-a3a9-f98dba1b1279。

自动化验证：全仓 lint 和 typecheck 通过；299 个定向测试通过，另有 1 个既有 skip；全仓 build 通过。

测试平台

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

环境（可选）

本地开发入口，one-shot stream-json 模式，启用 safe mode，approval mode 为 yolo，未启用 sandbox，通过 OpenAI-compatible endpoint 真实调用 qwen3.6-max-preview。

风险与范围

• 主要风险或取舍：仅当 registry 当前状态明确为 cancelled 时才丢弃已排队的 running 事件，因此与自然完成或失败竞态的事件仍可正常投递。
• 未验证 / 范围外：真实交互式 TUI 行为以及 Windows/Linux 运行时行为；相关路径由定向单测或 CI 覆盖。
• 破坏性变更 / 迁移说明：无。

关联 Issue

Resolves #7566

[yiliang114]

E2E Test Report

• Branch / commit: cx/fix-7566-monitor-cancel-notification / f081baebe3
• Entrypoint: local scripts/dev.js, one-shot stream-json mode
• Model: real qwen3.6-max-preview through the configured OpenAI-compatible endpoint; model and tool protocol were not mocked
• Scenario: start a monitor running while true; do echo ready; sleep 1; done, immediately stop the returned monitor ID with task_stop, return STOPPED, and return NOTIFICATION_ACK only if a later task notification arrives
• Expected final state: one monitor call, one task-stop call, STOPPED, no notification user record, no acknowledgement turn, and no remaining monitor process

Baseline failure

The pre-fix real reproduction recorded the cancelled/running monitor notification as a notification user message, made an extra model request with 17,395 input tokens, and returned NOTIFICATION_ACK.

Fixed result

Final session: 41558468-2323-4df8-a3a9-f98dba1b1279

monitor     mon_cc7f4b1d75544b78   success
task_stop  mon_cc7f4b1d75544b78   success
assistant                            STOPPED
result                               success

{
  "lines": 16,
  "notification_users": 0,
  "api_responses": 4,
  "monitor_calls": 1,
  "task_stop_calls": 1,
  "stopped_texts": 1,
  "notification_acks": 0
}

The process table contained no matching monitor command after the CLI exited.

Verdict: PASS

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓

Problem: observed bug with solid evidence — issue #7566 includes reproduction steps, a real model call consuming 17,395 input tokens on the stale notification turn, and example notification XML. Clearly not theoretical.

Direction: aligned. After an explicit task_stop, the synchronous tool result already confirms cancellation; emitting a separate notification turn is redundant and wasteful. The fix correctly suppresses the terminal notification at the source and filters stale queued running events at drain time across all three client paths (interactive, persistent stream-json, one-shot headless).

Size: core path packages/core/src/tools/task-stop.ts touched — 2 production lines (1 add + 1 del). Total production: ~50 lines across 4 source files; test: ~197 lines; docs: 39 lines. Well within bounds.

Approach: scope feels right — every edit serves the stated goal. The { notify: false } option already exists in the monitor registry and is well-tested; reusing it here is the minimal path. The drain-time filter is the correct complement for the race between queue and cancel. No drive-by changes or scope creep.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓

问题：已观测到的 bug，证据充分——issue #7566 包含复现步骤、真实模型调用消耗 17,395 个输入 token 的额外通知回合，以及示例通知 XML。明确不是理论性问题。

方向：对齐。显式 task_stop 后，同步工具结果已确认取消；再发一个通知回合是冗余且浪费的。修复正确地在源头抑制了终态通知，并在三个客户端路径（交互式、持久 stream-json、一次性 headless）的消费时过滤了过期的排队 running 事件。

规模：核心路径 packages/core/src/tools/task-stop.ts 被触及——2 行生产代码（1 增 + 1 删）。总生产代码约 50 行（4 个源文件）；测试约 197 行；文档 39 行。在合理范围内。

方案：范围合理——每处改动都服务于既定目标。{ notify: false } 选项在 monitor registry 中已存在且经过充分测试；在此复用是最小路径。消费时过滤是处理排队与取消之间竞态的正确补充。无顺手改动或范围蔓延。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-preview

_{Reviewed at f081baebe31005d49e884ff02ccf206b2ef089fe · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code Review

Clean implementation. The approach is exactly what I'd propose independently: suppress the terminal notification at the source (task_stop → cancel(id, { notify: false })), and filter stale queued running events at drain time in each client path.

The { notify: false } option already exists in monitorRegistry.cancel() and is well-tested — reusing it here is the minimal change. The drain-time filter is the correct complement for the race between a queued running event and explicit cancellation.

All three client paths are covered consistently:

• Interactive (useGeminiStream.ts): backwards iteration to splice cancelled events from the notification queue before drain
• Persistent stream-json (session.ts): filter at the top of processMonitorNotificationBatch
• One-shot headless (nonInteractiveCli.ts): isCancelledMonitorEvent helper applied at both drain points

The config addition to the useGeminiStream effect dependency array is correct — the effect now reads config.getMonitorRegistry().

No critical blockers. No convention violations. Tests are collocated and cover the new behavior in all three paths plus the core task_stop change.

Real-Scenario Testing

One-shot stream-json mode, real qwen3.8-max-preview model, same prompt for both runs: start a monitor printing "tick" every 2s, immediately task_stop it, respond STOPPED, respond NOTIFICATION_ACK only if a notification arrives later.

Before (installed qwen v0.20.0)

$ qwen -p '<prompt>' --output-format stream-json --yolo

{"type":"system","subtype":"task_notification",...,"data":{"task_id":"mon_2e1a98d1f1414be3",...,"status":"running"}}
{"type":"system","subtype":"task_notification",...,"data":{"task_id":"mon_2e1a98d1f1414be3",...,"status":"running"}}
{"type":"system","subtype":"task_notification",...,"data":{"task_id":"mon_2e1a98d1f1414be3",...,"status":"cancelled"}}
{"type":"assistant",...,"content":[{"type":"text","text":"NOTIFICATION_ACK"}],...}
{"type":"result","subtype":"success",...,"num_turns":5,"result":"NOTIFICATION_ACK","usage":{"input_tokens":130306,...}}

Bug reproduced: 2 stale running notifications + 1 cancelled notification triggered an extra model turn → NOTIFICATION_ACK, 5 turns, 130,306 input tokens.

After (this PR via npm run dev)

$ npm run dev -- -p '<prompt>' --output-format stream-json --yolo

{"type":"assistant",...,"content":[{"type":"text","text":"STOPPED"}],...}
{"type":"result","subtype":"success",...,"num_turns":4,"result":"STOPPED","usage":{"input_tokens":100260,...}}

Fixed: zero notification records, zero NOTIFICATION_ACK, model returned only STOPPED. 4 turns, 100,260 input tokens (~30K saved).

Unit Tests

Test file	Result
packages/core/src/tools/task-stop.test.ts	14 passed
packages/cli/src/nonInteractive/session.test.ts	38 passed
packages/cli/src/nonInteractiveCli.test.ts	87 passed, 1 skipped (pre-existing)
packages/cli/src/ui/hooks/useGeminiStream.test.tsx	160 passed

Typecheck: both packages/core and packages/cli pass tsc --noEmit.

中文说明

代码审查

实现干净。方案与我独立提出的完全一致：在源头抑制终态通知（task_stop → cancel(id, { notify: false })），并在各客户端路径的消费时过滤过期的排队 running 事件。

{ notify: false } 选项在 monitorRegistry.cancel() 中已存在且经过充分测试——在此复用是最小改动。消费时过滤是处理排队 running 事件与显式取消之间竞态的正确补充。

三个客户端路径均一致覆盖：

• 交互式（useGeminiStream.ts）：反向迭代从通知队列中移除已取消的事件
• 持久 stream-json（session.ts）：在 processMonitorNotificationBatch 顶部过滤
• 一次性 headless（nonInteractiveCli.ts）：isCancelledMonitorEvent 辅助函数应用于两个消费点

useGeminiStream effect 依赖数组中添加 config 是正确的——effect 现在读取 config.getMonitorRegistry()。

无关键阻塞项。无规范违反。测试与源码同目录，覆盖了三个路径和核心 task_stop 改动。

真实场景测试

One-shot stream-json 模式，真实 qwen3.8-max-preview 模型，两次运行使用相同提示：启动一个每 2 秒打印 "tick" 的 monitor，立即用 task_stop 停止，回复 STOPPED，仅在收到通知时回复 NOTIFICATION_ACK。

修复前（v0.20.0）：2 条过期 running 通知 + 1 条 cancelled 通知触发了额外模型回合 → NOTIFICATION_ACK，5 个回合，130,306 个输入 token。

修复后（本 PR）：零通知记录，零 NOTIFICATION_ACK，模型仅返回 STOPPED。4 个回合，100,260 个输入 token（节省约 30K）。

单元测试全部通过（299 个测试，1 个既有 skip）。Typecheck 通过。

— Qwen Code · qwen3.8-max-preview

_{Reviewed at f081baebe31005d49e884ff02ccf206b2ef089fe · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 5/5 — clean fix for a real, reproduced bug; minimal change, comprehensive tests, clear before/after evidence.

This is a textbook bug fix. The problem is real and well-documented in #7566 — stale monitor notifications triggering unnecessary model turns after explicit task_stop, consuming tokens and polluting the conversation. The fix is exactly what I'd propose: suppress the terminal notification at the source (the tool result already confirms cancellation), and filter stale queued running events at drain time. Every edit in the diff serves the stated goal — no drive-by changes, no over-engineering.

The before/after run confirms it works: the installed build (v0.20.0) produced NOTIFICATION_ACK across 5 turns and 130K input tokens; the PR code produces only STOPPED across 4 turns and 100K tokens. All 299 targeted tests pass, typecheck is clean.

If I had to maintain this in six months, I'd thank the author — the design doc explains the rationale, the tests cover all three client paths, and the change is small enough to reason about at a glance.

中文说明

置信度：5/5 — 针对真实已复现 bug 的干净修复；最小改动，全面测试，清晰的 before/after 证据。

这是一个教科书式的 bug 修复。问题真实且在 #7566 中有详细记录——过期的 monitor 通知在显式 task_stop 后触发不必要的模型回合，消耗 token 并污染对话。修复方案与我独立提出的完全一致：在源头抑制终态通知（工具结果已确认取消），并在消费时过滤过期的排队 running 事件。diff 中每处改动都服务于既定目标——无顺手改动，无过度工程。

Before/after 运行确认修复有效：安装版本（v0.20.0）产生 NOTIFICATION_ACK，5 个回合，130K 输入 token；PR 代码仅产生 STOPPED，4 个回合，100K token。全部 299 个定向测试通过，typecheck 干净。

如果六个月后维护这段代码，我会感谢作者——设计文档解释了原理，测试覆盖了三个客户端路径，改动小到可以一目了然地推理。

— Qwen Code · qwen3.8-max-preview

_{Reviewed at f081baebe31005d49e884ff02ccf206b2ef089fe · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[wenshao]

Maintainer E2E Verification Report

Verified locally on macOS (darwin arm64) using a git worktree build of this PR branch (f081baeb), with a real model call through an OpenAI-compatible endpoint.

Test Setup

• Build: npm install && npm run build && npm run bundle — all passed
• Mode: one-shot stream-json, --safe-mode, --approval-mode yolo, no sandbox
• Model: qwen3.8-max-preview via OpenAI-compatible API
• Prompt: Start a monitor (while true; do echo tick-7573; sleep 60; done), immediately task_stop it, reply STOPPED; reply NOTIFICATION_ACK only if a later notification arrives.

E2E Result: ✅ PASS

The model executed exactly 4 turns: tool_search → monitor → task_stop → "STOPPED".

Check	Expected	Actual	Status
Notification user envelopes after cancel	0	0	✅
task_notification system messages	0	0	✅
NOTIFICATION_ACK in responses	0	0	✅
Monitor tool calls	1	1	✅
task_stop tool calls	1	1	✅
Residual monitor processes	0	0	✅
Final result	STOPPED	STOPPED	✅
Total JSONL lines	—	14	—
Total tokens	—	71,116	—
Duration	—	14.3s	—

E2E Flow

Verification Summary

Raw JSONL Output

Unit Tests (all 4 changed test files)

Test file	Result
packages/core/src/tools/task-stop.test.ts	14 passed ✅
packages/cli/src/nonInteractive/session.test.ts	38 passed ✅
packages/cli/src/nonInteractiveCli.test.ts	87 passed, 1 skipped (pre-existing) ✅
packages/cli/src/ui/hooks/useGeminiStream.test.tsx	160 passed ✅
Total	299 passed ✅

Conclusion

The fix works as designed: task_stop cancels the monitor silently ({ notify: false }), and all three notification drain paths (interactive useGeminiStream, persistent session.ts, one-shot nonInteractiveCli.ts) correctly discard queued running events for explicitly cancelled monitors. No spurious notification turn, no extra model request, no residual process.

Evidence artifacts: wenshao/qwen-code@evidence/pr-7573-e2e

中文验证报告

维护者 E2E 验证报告

在 macOS (darwin arm64) 本地使用 git worktree 构建本 PR 分支 (f081baeb)，通过 OpenAI-compatible endpoint 进行真实模型调用验证。

测试环境

• 构建: npm install && npm run build && npm run bundle — 全部通过
• 模式: one-shot stream-json，--safe-mode，--approval-mode yolo，无 sandbox
• 模型: qwen3.8-max-preview，通过 OpenAI-compatible API
• 提示词: 启动 monitor（while true; do echo tick-7573; sleep 60; done），立即 task_stop 停止，回复 STOPPED；仅在收到后续通知时回复 NOTIFICATION_ACK。

E2E 结果: ✅ 通过

模型精确执行 4 个 turn：tool_search → monitor → task_stop → "STOPPED"。

检查项	预期	实际	状态
取消后通知 user envelope	0	0	✅
task_notification 系统消息	0	0	✅
响应中 NOTIFICATION_ACK	0	0	✅
Monitor 工具调用	1	1	✅
task_stop 工具调用	1	1	✅
残留 monitor 进程	0	0	✅
最终结果	STOPPED	STOPPED	✅
JSONL 总行数	—	14	—
总 token 数	—	71,116	—
耗时	—	14.3s	—

单元测试（4 个变更测试文件全部通过）

测试文件	结果
task-stop.test.ts	14 通过 ✅
session.test.ts	38 通过 ✅
nonInteractiveCli.test.ts	87 通过，1 跳过（既有）✅
useGeminiStream.test.tsx	160 通过 ✅
合计	299 通过 ✅

结论

修复按设计工作：task_stop 静默取消 monitor（{ notify: false }），三条通知消费路径（交互式 useGeminiStream、持久化 session.ts、一次性 nonInteractiveCli.ts）均正确丢弃已显式取消 monitor 的排队 running 事件。无多余通知 turn、无额外模型请求、无残留进程。

证据文件：wenshao/qwen-code@evidence/pr-7573-e2e

[wenshao]

Maintainer Verification — Independent Re-run (load-bearing A/B)

Re-verified locally on macOS (darwin arm64) in an isolated detached worktree at the PR head f081baeb, running vitest against the real source (CLI vitest aliases @qwen-code/qwen-code-core → worktree source; the PR touches no package.json, so deps were symlinked from a base-aligned main checkout). This round complements the earlier real-model E2E report by adding a deterministic before/after proof that each fix path is load-bearing.

1. All 4 changed test files pass on the PR head — 299 passed, 1 pre-existing skip

Test file	Package	Result
packages/core/src/tools/task-stop.test.ts	core	14 passed ✅
packages/cli/src/nonInteractive/session.test.ts	cli · persistent stream-json	38 passed ✅
packages/cli/src/nonInteractiveCli.test.ts	cli · one-shot headless	87 passed, 1 skipped (pre-existing) ✅
packages/cli/src/ui/hooks/useGeminiStream.test.tsx	cli · interactive TUI	160 passed ✅
Total		299 passed / 1 skip / 0 failed

prettier --check clean on all 9 changed files.

2. Load-bearing A/B — every fix path is proven necessary

I reverted only the 4 changed source files to their merge-base (dc7427910) content, kept the PR's test files, and re-ran. Exactly 4 tests flip fail→pass — one per changed path — while every other test passes in both configurations, so the change is isolated, not incidental.

Changed source (fix)	Discriminating test	Base	Head
task-stop.ts — cancel(id,{notify:false})	cancels a running monitor	✗ FAIL	✓ PASS
session.ts — drain-batch filter	drops a queued running monitor event after cancellation	✗ FAIL	✓ PASS
nonInteractiveCli.ts — isCancelledMonitorEvent	drops a queued running monitor event after cancellation	✗ FAIL	✓ PASS
useGeminiStream.ts — queue splice guard	drops a queued running monitor event after cancellation	✗ FAIL	✓ PASS

On base, the one-shot headless failure is the bug itself: the queued running event is not dropped, so runNonInteractive drains it and starts a second model turn (surfaced as TypeError: reading Symbol.asyncIterator on the un-mocked 2nd stream) — precisely the extra request described in #7566.

3. Mechanism reads correctly — no over-suppression

• Core (monitorRegistry.ts:300-306): task_stop now calls cancel(taskId, { notify: false }), which settles to cancelled, sets notified = true, aborts, and wakes the owner — without emitTerminalNotification(). The default (non-task_stop) branch still aborts-then-notifies, so terminal cancelled notifications from other callers are preserved. notify:false is a pre-existing capability (owner-agent teardown), reused here.
• All 3 client guards drop a queued event only when status === 'running' and the registry entry is now cancelled. Natural completed/failed events (status !== 'running') and running events of still-running monitors always pass through — matching the PR's stated risk scope.

Conclusion — ✅ merge-ready

The fix is correct, minimal, and every path is load-bearing and regression-guarded. Combined with the earlier real-model E2E (no notification turn after task_stop, session 41558468…), I'm satisfied this resolves #7566. LGTM.

_{Evidence hosted at QwenLM/qwen-code@pr-assets/pr-7573-verify. Verified head: f081baebe31005d49e884ff02ccf206b2ef089fe.}

中文验证报告

维护者验证 — 独立复跑（load-bearing A/B）

在 macOS (darwin arm64) 本地，于独立的 detached worktree（PR head f081baeb）中，针对真实源码运行 vitest（CLI vitest 将 @qwen-code/qwen-code-core 别名指向 worktree 源码；本 PR 未改动任何 package.json，故从与 base 对齐的 main checkout 软链 node_modules）。本轮在此前真实模型 E2E 报告的基础上，补充一份确定性的 before/after 证据，证明每条修复路径都是必要的（load-bearing）。

1. 4 个变更测试文件在 PR head 全部通过 — 299 通过，1 个既有 skip

测试文件	包	结果
task-stop.test.ts	core	14 通过 ✅
session.test.ts	cli · 持久化 stream-json	38 通过 ✅
nonInteractiveCli.test.ts	cli · 一次性 headless	87 通过，1 跳过（既有）✅
useGeminiStream.test.tsx	cli · 交互式 TUI	160 通过 ✅
合计		299 通过 / 1 跳过 / 0 失败

prettier --check 对全部 9 个变更文件均通过。

2. Load-bearing A/B — 每条修复路径都被证明是必要的

我仅将 4 个变更 source 文件回退到 merge-base（dc7427910）内容，保留 PR 的 test 文件后复跑。恰好 4 个测试从失败翻转为通过——每条变更路径一个，而其余所有测试在两种配置下都通过，说明改动是精准隔离的，而非偶然。

变更 source（修复）	判别性测试	Base	Head
task-stop.ts — cancel(id,{notify:false})	cancels a running monitor	✗ 失败	✓ 通过
session.ts — drain-batch 过滤	drops a queued running monitor event after cancellation	✗ 失败	✓ 通过
nonInteractiveCli.ts — isCancelledMonitorEvent	同上	✗ 失败	✓ 通过
useGeminiStream.ts — 队列 splice 守卫	同上	✗ 失败	✓ 通过

在 base 上，一次性 headless 的失败正是该 bug 本身：排队的 running 事件没有被丢弃，于是 runNonInteractive 消费它并发起了第二次模型调用（表现为对未 mock 的第二个 stream 读取 Symbol.asyncIterator 抛 TypeError）——正是 #7566 描述的额外请求。

3. 机制正确 — 不会过度抑制

• Core（monitorRegistry.ts:300-306）： task_stop 现在调用 cancel(taskId, { notify: false })，将状态 settle 为 cancelled、置 notified = true、abort 并唤醒 owner，但不调用 emitTerminalNotification()。默认（非 task_stop）分支仍先 abort 再 notify，因此其它调用方的终态 cancelled 通知照常投递。notify:false 是既有能力（owner-agent teardown），此处复用。
• 三条客户端守卫仅在 status === 'running' 且 registry 条目当前为 cancelled 时才丢弃排队事件。自然的 completed/failed（status !== 'running'）以及仍在运行的 monitor 的 running 事件始终放行——与 PR 声明的风险范围一致。

结论 — ✅ 可合并

修复正确、最小化，每条路径都 load-bearing 且有回归保护。结合此前的真实模型 E2E（task_stop 后无通知 turn，会话 41558468…），确认本 PR 解决了 #7566。LGTM。