Codecov Report

❌ Patch coverage is 92.85714% with 2 lines in your changes missing coverage. Please review.

📢 Thoughts on this report? Let us know!

Issue: Code coverage gap noted by Codecov (74.4% patch coverage).

The Codecov report indicates 11 missing lines in src/strands/event_loop/event_loop.py. Consider adding unit tests specifically for:

1. Checkpoint 1 cancellation (cycle start) - lines 152-164
2. Checkpoint 2 cancellation (before model call) - lines 346-359
3. Checkpoint 4 cancellation (before tool execution) - lines 522-533

While the integration tests cover many scenarios, targeted unit tests with mock signals would improve coverage and make it easier to verify each checkpoint works correctly in isolation.

Review Summary

Assessment: Request Changes

This is a well-designed feature that adds graceful cancellation support to agents. The implementation is thread-safe, has clear checkpoints, and includes comprehensive tests. However, there's a critical issue that needs to be addressed before merging.

The core implementation is solid - the four checkpoint design is sensible and the thread-safety approach using threading.Lock is appropriate.

🔬 Adversarial Testing: Cancel + Interrupt Interactions

I ran additional adversarial tests focusing on how cancel() interacts with interrupts, concurrent tool execution, and partial results.

Result: ✅ No critical bugs found — 2 design observations documented below.

# Cancel called after first tool starts → BOTH tools complete fully
execution_log = ['start_0.1', 'end_0.1', 'start_0.5', 'end_0.5']

result = await agent.invoke_async("start")  # Triggers interrupt
assert result.stop_reason == "interrupt"

agent.cancel()  # User wants to cancel

# This FAILS with TypeError!
await agent.invoke_async("normal prompt")  # Must resume from interrupt

# To recover, must manually:
agent._interrupt_state.deactivate()
agent._cancel_signal.clear()

Agent States:
- IDLE: Agent not running, ready for invocation
- STREAMING: Model is generating response
- TOOL_PENDING: Model returned tool_use(s), about to execute
- TOOL_EXECUTING: Currently executing a tool
- INTERRUPTED: Waiting for human input (interruptResponse)
- CANCELLED: Invocation was cancelled

Key Transitions:
- STREAMING --cancel()--> Check at next chunk, return "cancelled"
- TOOL_PENDING --cancel()--> All tools get cancel results
- TOOL_EXECUTING --cancel()--> Current tool COMPLETES, remaining get cancel results
- INTERRUPTED --cancel()--> Signal set, but still in INTERRUPTED state

Conclusion: The implementation is solid. The two findings are design observations, not bugs — both behaviors are defensible and appear intentional. Consider documenting the cancel + interrupt interaction for users.

@jgoyani1 Hello, thank you very much for contributing this feature. I tested it as soon as the new version was released.

However, I noticed an issue with the token usage statistics when a request is canceled.

I did a quick test and found that after cancellation, the reported token count is inaccurate. It doesn’t include the size of each prompt, and it also misses the tokens that have already been generated. Right now, it seems to be counting only a very small portion of the total.

Normal output without interruption

Total: 12087
Input: 11699
Output: 388

Interrupted near the end of output

Total: 35
Input: 0
Output: 35

Accurate token statistics would be very helpful for billing-related applications.

@tahitimoon

The root cause is in process_stream (streaming.py). When cancellation is detected mid-stream, the function returns immediately with usage=Usage(inputTokens=0, outputTokens=0, totalTokens=0) because:

1. Model providers (Bedrock, Anthropic, etc.) report token usage in the final metadata event of the stream.
2. The metadata event is always the last chunk — it comes after messageStop.
3. When we cancel mid-stream, we break out before the metadata chunk arrives.
4. So usage stays at its initialized zero values.

Would investigate more on how to fetch this values and then post an update here if its possible to get the token count on the go while streaming.

@tahitimoon

The root cause is in process_stream (streaming.py). When cancellation is detected mid-stream, the function returns immediately with usage=Usage(inputTokens=0, outputTokens=0, totalTokens=0) because:

1. Model providers (Bedrock, Anthropic, etc.) report token usage in the final metadata event of the stream.
2. The metadata event is always the last chunk — it comes after messageStop.
3. When we cancel mid-stream, we break out before the metadata chunk arrives.
4. So usage stays at its initialized zero values.

Would investigate more on how to fetch this values and then post an update here if its possible to get the token count on the go while streaming.

thx，here’s my current approach:

After the output is interrupted, I can’t get the complete usage data returned by the model provider. So for now, I’m doing a local rough estimate with tiktoken using cl100k_base. For the input side, I count tokens by concatenating the full context sent to the model each time, including the system prompt, conversation history, tool results, and so on. For the output side, I count tokens by concatenating the text chunks that were already streamed back.

There are two issues with this approach:

cl100k_base is the tokenizer used for OpenAI models, but its tokenization rules differ from those used by Claude, DeepSeek, Kimi, Grok, and others, so the numbers will inevitably be off.

The estimated results are only for display and reference. They do not represent the actual token count used for billing by the provider.