test(a2a): lock in that CancelTask halts the running turn

[mabry1985]

Follow-up to #338 — which I filed wrongly and have closed as invalid. This ships the regression test instead of a fix.

What happened

I reported that CancelTask only marked the row canceled while inference kept running. That was a misread. Verified against a real a2a-sdk app wired exactly as server/a2a.py mounts it:

turn running: 19 ticks elapsed
cancel response: {'status': {'state': 'TASK_STATE_CANCELED', ...}}
ticks at cancel=19  ticks 1.5s later=19
VERDICT: STOPPED — the turn halted on cancel
stream saw CancelledError: True

ActiveTask.cancel (a2a-sdk active_task.py:702-711) cancels the producer task before calling ProtoPenExecutor.cancel, so CancelledError propagates into our stream. Our executor only publishing the status is correct, not cosmetic.

The original evidence was confounded: during the #337 runaway I cancelled 8 tasks while ~2,000 turns were running concurrently (every SendMessage gets its own producer task; they serialize under contention, which is why throughput looked like ~1 cycle/min). Cancelling 8 of 2,000 changed nothing observable.

Why ship anything

The property is real but entirely dependent on SDK internals, and a2a_registry.py already documents that an SDK bump can move exactly these internals (protoAgent #1713) — it degrades to a logged warning rather than a crash, so a regression here would be silent. Nothing covered it.

The test starts a long turn, cancels it mid-flight, and asserts the stream stops advancing and observes CancelledError.

Verified to bite: neutering the producer cancellation — leaving only the status write, exactly the behavior #338 described — fails it with turn kept working after cancel (18 → 44 ticks), with the task still reporting TASK_STATE_CANCELED.

36 passed in test_a2a_handler.py; ruff check + format clean.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@mabry1985, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 53 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: f162c396-e548-470c-8040-0a2c14069bff

📥 Commits

Reviewing files that changed from the base of the PR and between 55e0566 and e0d8284.

📒 Files selected for processing (1)

• tests/test_a2a_handler.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}