AsyncExecutor.close() hangs forever on tasks blocked in synchronous code

[neubig]

Actual Behavior

AsyncExecutor.close() hangs forever when a task is blocked in synchronous code (a worker thread that ignores cancellation). This is the same class of bug as #4546 but specifically about the close() path.

When close() is called (e.g. during LocalConversation.close() → tool executor cleanup), it calls portal_cm.__exit__(None, None, None) which takes anyio's graceful path (cancel_remaining=False) and waits for in-flight tasks to finish on their own. If a task is blocked in a C-level lock, blocking I/O, or a futex, it never finishes — close() hangs forever, holding the conversation's lifecycle lock.

Reproduce

uv run pytest tests/sdk/utils/test_cancellation_deadlock.py::test_async_executor_close_hangs_on_blocking_task -xvs

The test fails after 5s:

AssertionError: AsyncExecutor.close() hung >5s on a task blocked in a worker thread.
The task ignores cancellation (blocked in sync code), and close() does not bound the wait.

Expected Behavior

close() must never hang forever. It should cancel remaining tasks and bound the thread join with a timeout, abandoning the daemon thread if it doesn't respond.

Acceptance Criteria

• close() returns within a bounded timeout even when a task is blocked in synchronous code
• The failing test passes
• All existing test_async_executor.py tests still pass

Related

• PR fix(sdk): bound AsyncExecutor.close() so it cannot hang forever #4548 — a fix for this exact issue (changes requested; should be re-evaluated against this test)
• Issue [Bug]: AsyncExecutor.close() can block forever, wedging conversation shutdown #4546 — the original bug report
• Issue perf: replace global _lifecycle_lock with per-conversation locks to eliminate cross-conversation wedges #4569 — per-conversation locks (merged) mitigates cross-conversation impact but doesn't fix close() itself

[github-actions]

⚠️ Not yet ready-for-dev

This issue does not yet meet the readiness criteria, so the
ready-for-dev label has not been applied (or has been removed).
The criteria are type-specific:

Bug reports (bug label):

• The ### Actual Behavior section must describe reproducible SDK steps
  and include a command such as python, pytest, uv, or pip.
• An ### Acceptance Criteria section with at least one checklist item (- [ ] …).

Enhancements (enhancement label):

• A ### Desired Behavior section.
• An ### Acceptance Criteria section with at least one checklist item.

What is missing:

• The Actual Behavior section must include a reproducible SDK command such as python, pytest, uv, or pip.

Edit the issue to address the gaps and the ready-for-dev label will be
applied automatically.

This is an automated check — no AI was used to generate this comment.

[all-hands-bot]

#4597 is a near-exact duplicate of #4546. Both report AsyncExecutor.close() hanging forever due to the same two root causes: (1) portal_cm.exit(None, None, None) uses cancel_remaining=False, waiting indefinitely for in-flight tasks, and (2) unbounded thread.join(). #4597 explicitly self-identifies as 'the same class of bug as #4546 but specifically about the close() path' — but #4546 IS about the close() path. Both reference PR #4548 as the fix. The only incremental content in #4597 is a specific test file path, which can be added as a comment on #4546.

Found 2 possible duplicate issues:

1. #4546 — [Bug]: AsyncExecutor.close() can block forever, wedging conversation shutdown
2. #4555 — [Bug]: Agent Server event endpoints hang indefinitely when LocalConversation cleanup blocks

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

This comment was created by an AI assistant (OpenHands) on behalf of the repository maintainer.

[neubig]

Closing as a duplicate of #4546. Both issues track the same AsyncExecutor.close() shutdown hang; the specific synchronous-task case is already covered by the original issue.

This comment was created by an AI agent (OpenHands) on behalf of the user.

[neubig]

Thank you for the additional reproduction case. Closing this issue as a duplicate of #4546 so the AsyncExecutor shutdown work remains consolidated in the original report.

This action was performed by an AI agent (OpenHands) on behalf of the user.