respond() intermittently never returns after parallel tool calls

Start by running the reproduction script repeatedly and instrumenting LanguageModelSession.respond() around tool completion. The issue points at Tool._c_callback_impl, _run_in_thread, and FMBridgedToolFinishCall, so trace how each parallel callback finishes and how completion is signalled back to the awaiting response. The fix is confirmed when the script completes consistently and the callback-thread event-loop behavior is either corrected or documented.

LanguageModelSession.respond() intermittently never returns after the model issues several tool calls in one response. Every tool callback has already finished, no further callback arrives, and the awaited response never completes. Only an outer timeout ends it. It happens whether or not the tool calls raise.

Environment

• apple-fm-sdk 0.2.1
• macOS 27.0.1 (26A434), Apple M4
• Python 3.14.10

Reproduction

The script below uses only the SDK. The model is asked to create five files and requests five write calls in one response. In this version the tool raises from the third call onward; changing count > 2 to count > 1000 makes every call succeed, which also hangs (see below). Run it repeatedly.

import asyncio
import tempfile
import threading
import time
from pathlib import Path

import apple_fm_sdk as fm
from apple_fm_sdk.generation_property import Property
from apple_fm_sdk.generation_schema import GenerationSchema

calls: list[float] = []
lock = threading.Lock()


class Write(fm.Tool):
    name = "write"
    description = "Create a new text file with the given content."

    @property
    def arguments_schema(self) -> GenerationSchema:
        return GenerationSchema(
            type_class=type("WriteArguments", (), {}),
            description="File to create",
            properties=[
                Property(name="path", type_class=str, description="File path"),
                Property(name="content", type_class=str, description="File content"),
            ],
        )

    async def call(self, args: fm.GeneratedContent) -> str:
        with lock:
            calls.append(time.perf_counter())
            count = len(calls)
        if count > 2:  # Calls 3+ fail; use count > 1000 to make every call succeed.
            raise RuntimeError("tool-call budget exhausted")
        path = Path(args.value(for_property="path"))
        path.write_text(args.value(for_property="content"))
        return "created"


async def main() -> None:
    with tempfile.TemporaryDirectory() as directory:
        session = fm.LanguageModelSession(
            instructions="Use an available tool when it can answer.",
            tools=[Write()],
        )
        started = time.perf_counter()
        try:
            async with asyncio.timeout(45):
                await session.respond(
                    f"Create five files named one.txt through five.txt in "
                    f"{directory}, each containing its own number."
                )
            print(f"done in {time.perf_counter() - started:.0f}s, calls={len(calls)}")
        except TimeoutError:
            alive = [thread.name for thread in threading.enumerate()]
            print(f"HUNG: calls={len(calls)}, live threads={alive}")


if __name__ == "__main__":
    asyncio.run(main())

Observed

A normal run finishes in 10–15 s. In every hang:

• all five callbacks had run, and no further callback arrived in the remaining ~30 s;
• only MainThread was alive, so every _run_in_thread callback thread had finished, including its FMBridgedToolFinishCall;
• the awaited respond() never completed.

The five callbacks run on separate threads and finish close together, so a race in the native bridge when several tool calls of one response complete concurrently seems plausible. I have not confirmed that.

Expected

respond() returns once the tool calls have completed, as it does in most runs.

Workaround

Wrapping respond() in asyncio.timeout(...) bounds the hang; cancellation works.

Related observation

Without a running event loop on the native callback thread, Tool._c_callback_impl runs each callback on a new event loop in a new thread (_run_in_thread). Objects bound to the caller's loop, such as an asyncio.Lock shared between tools or an MCP client session, then block or deadlock when used from a callback. Scheduling such work back onto the session's loop with run_coroutine_threadsafe works around it. If this behavior is intended, documenting it in the tool-calling docs would help; I can open a separate issue if useful.