[ShotaroKataoka]

Summary

test_a_call_to_the_manage_tool_by_name_is_refused_and_the_task_keeps_running read the task status once, right after invoke_async, and sometimes saw ['queued'] (#626). The cause is in how Strands publishes task updates, not in the test's timing budget.

Strands' in-process engine runs on its own runtime thread and publishes every update with loop.call_soon(self._run_notification, …). The task is marked working in the first step of _execute, but that notification is queued behind the callback that hands the dispatch ack back to the agent's thread. When the GIL goes to the agent thread first, the turn (refused manage call, final text) can finish before the runtime thread stores the working snapshot in agent.state.

test_cancel_all_cancels_a_pending_task has the same single read of ["working"] and could flake the same way.

Production is not affected: session_runtime only uses background.pending(), which counts queued and working alike.

Changes

• tests/test_agent_background.py
  • The cancel-all test polls for working with the file's _until helper (timeout 5 s) instead of reading it once.
  • The refusal test no longer asserts working. It accepts queued or working right after the turn (never cancelled) and checks that the task ends completed. It does not wait for working: the task takes 0.4 s, so it can reach completed before a poll sees working.

Testing

• Reproduced the CI failure: a probe plugin that delays _run_notification for working by 0.1 s makes both tests on main fail with assert ['queued'] == ['working']. With this change the whole file passes under the same probe.
• 30 runs of the two tests in a loop without the probe: 0 failures.
• ruff check tests/test_agent_background.py

Notes

No CHANGELOG entry: test-only change.

Closes #626

🤖 Created by Kiro Crew