[nijanthanh]

Summary

A workflow activation timeout currently cancels the asyncio executor future even though its thread may still be running. Safe eviction can consequently start another activation on the same instance and acknowledge eviction before the original execution exits. Separately, cleanup that succeeds during the retry delay is submitted again because the retry loop treats every completed future as a reason to retry.

Use non-cancelling waits and consume the executor result before deciding whether to retry:

• Preserve timed-out activation futures and wait for actual completion before eviction.
• Reuse the same eviction future across timeouts; retry only after an execution has finished with an exception.
• Propagate handler cancellation before removing the cached instance or acknowledging eviction, while retaining the preceding activation future.
• Distinguish an execution raising TimeoutError from expiration of the deadlock timer.

Safe eviction still waits for a permanently blocked thread; this change does not forcibly terminate threads or disable safe eviction.

Validation

On macOS ARM64 / Python 3.12, with the native bridge built from the pinned Core revision:

• poe lint — passed, including Ruff, Pyright, mypy, basedpyright, and docstyle.
• poe test -n 0 tests/worker/test_workflow_eviction_unit.py — 8 passed.
• poe test -n 0 tests/worker/test_workflow_eviction.py — 3 passed as part of the focused regression run.
• poe test -n 0 tests/worker/test_workflow.py -k 'deadlock or eviction' — 8 passed.

The three new integration cases and the strengthened uninterruptible-deadlock test all failed on the unmodified baseline and passed with this change. Coverage includes overlapping activation prevention, success during retry backoff, premature eviction acknowledgment, actual deadlock interruption, completed execution failures, and handler cancellation.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[tconley1428]

Please elaborate on the actual issue you ran into. The description provided really doesn't give a concrete thing it is actually intended to prevent. You should file an issue with a more precise description before opening an intricate PR.

[nijanthanh]

My bad - was looking to create PR to understand what a potential fix would like. Didn't intend to notify you folks. Yes, will raise a more detailed issue. Thanks!