Route debug-mode activation via call_soon to fix Python 3.14 task nesting

The prior approach called workflow.activate(act) synchronously from
inside _handle_activation's coroutine. Python 3.14 raised:

  RuntimeError: Cannot enter into task <workflow run task>
    while another task <_handle_activation> is being executed.

3.14 tightened asyncio's task-step validation: a task cannot be entered
while another task on the same thread is mid-step. Our dispatch task
was mid-step when workflow.activate's internal _run_once tried to step
the workflow's own run task.

Fix: schedule workflow.activate as a `loop.call_soon` callback and
await a future the callback completes. The await suspends the dispatch
task (no longer mid-step), the callback runs as part of the loop's
ready-handle iteration (not inside any task), and the workflow's task
stepping then proceeds with no task currently being stepped.

The main loop is still blocked while the activation runs synchronously,
which is the intended single-stepping debug behavior.

Also drops the temporary 2-minute task_timeout from the test - that was
a wrong-direction guess at a symptom; the real issue was the structural
nested-task error.

Verified locally:
- Python 3.14: all 3 tests pass (previously failed deterministically)
- Python 3.13: all 3 tests pass (regression check)
- tests/worker/test_worker.py: 18 passed, 11 skipped, no regressions

Author: elidlocke

temporalio/worker/_workflow.py

@@ -271,6 +271,37 @@ async def drain_poll_queue(self) -> None:
             except PollShutdownError:
                 return
 
+    async def _activate_inline_for_debug(
+        self,
+        loop: asyncio.AbstractEventLoop,
+        workflow: _RunningWorkflow,
+        act: temporalio.bridge.proto.workflow_activation.WorkflowActivation,
+    ) -> temporalio.bridge.proto.workflow_completion.WorkflowActivationCompletion:
+        # Run `workflow.activate(act)` synchronously, but indirected through
+        # `loop.call_soon` so it executes outside the dispatch task's __step()
+        # context. Python 3.14's asyncio refuses to enter a task while another
+        # task on the same thread is mid-step; awaiting the future below
+        # suspends this dispatch task so the workflow's own task stepping does
+        # not collide with it.
+        future: asyncio.Future = loop.create_future()
+
+        def run_inline() -> None:
+            # The workflow's _run_once clears the running-loop registration to
+            # None when it exits. Save the main loop here and restore it after
+            # the activation so any code that runs subsequently still sees the
+            # right loop.
+            main_loop = asyncio._get_running_loop()
+            try:
+                completion = workflow.activate(act)
+                future.set_result(completion)
+            except BaseException as e:
+                future.set_exception(e)
+            finally:
+                asyncio._set_running_loop(main_loop)
+
+        loop.call_soon(run_inline)
+        return await future
+
     async def _handle_activation(
         self, act: temporalio.bridge.proto.workflow_activation.WorkflowActivation
     ) -> None:
@@ -362,16 +393,20 @@ async def _handle_activation(
 
             if self._debug_mode:
                 # Run activation inline on the asyncio main thread so
-                # interactive debuggers can read stdin. The loop blocks for
-                # the duration of the activation; this is the intended
-                # behavior when debugging.
-                # Save/restore the main loop registration because the
-                # workflow's custom event loop clears it inside _run_once.
-                main_loop = asyncio.get_running_loop()
-                try:
-                    completion = workflow.activate(act)
-                finally:
-                    asyncio._set_running_loop(main_loop)
+                # interactive debuggers (pdb, breakpoint(), IDE debuggers)
+                # can read stdin. We schedule the synchronous activation as
+                # a `call_soon` callback rather than calling it directly,
+                # so the dispatch task suspends at the `await` below and is
+                # no longer mid-`__step()` when the workflow's own task
+                # gets stepped inside `workflow.activate`. Python 3.14's
+                # asyncio refuses to enter a task while another task on
+                # the same thread is currently being executed; the
+                # call_soon detour avoids that nesting. The main loop is
+                # still blocked while the activation runs, which is the
+                # intended behavior when debugging.
+                completion = await self._activate_inline_for_debug(
+                    asyncio.get_running_loop(), workflow, act
+                )
             else:
                 # Run activation in separate thread so we can check if it's
                 # deadlocked
@@ -620,15 +655,12 @@ async def _handle_cache_eviction(
             while True:
                 try:
                     if self._debug_mode:
-                        # Inline eviction activation for debug mode.
-                        # Save/restore the main loop registration because
-                        # the workflow's custom event loop clears it inside
-                        # _run_once.
-                        main_loop = asyncio.get_running_loop()
-                        try:
-                            workflow.activate(act)
-                        finally:
-                            asyncio._set_running_loop(main_loop)
+                        # Eviction activation runs inline on the main thread
+                        # too. See `_activate_inline_for_debug` for why the
+                        # `call_soon` detour is needed on Python 3.14+.
+                        await self._activate_inline_for_debug(
+                            asyncio.get_running_loop(), workflow, act
+                        )
                     else:
                         # We only create the eviction task if we haven't already or
                         # it is done. This is because if it already is running and

tests/worker/test_breakpoint_hang.py

@@ -17,7 +17,6 @@
 import sys
 import threading
 import uuid
-from datetime import timedelta
 
 from temporalio import workflow
 from temporalio.client import Client
@@ -79,12 +78,6 @@ async def test_workflow_runs_on_main_thread_in_debug_mode(client: Client):
             ThreadCaptureWorkflow.run,
             id=f"wf-{uuid.uuid4()}",
             task_queue=task_queue,
-            # Conservative task_timeout to tolerate CI contention. The inline
-            # activation blocks the asyncio loop briefly; under heavy parallel
-            # CI load this can race the server's default workflow task timeout
-            # and cause task reassignment. Temporary mitigation while we
-            # diagnose the CI-specific hang against the bundled dev server.
-            task_timeout=timedelta(minutes=2),
         )
 
     main_name = threading.main_thread().name