respond() intermittently never returns after parallel tool calls

Abierto
  • ¿Algo no está bien?
#21 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
28/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
ai

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Variant Runs that hung
Script as shown: calls 3–5 raise 2 of 15
count > 1000: all calls succeed 1 of 15

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.

Lenguaje dominante
Python
Estrellas
1.4k
Forks
89
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apple/python-apple-fm-sdk

Todos los issues de apple/python-apple-fm-sdk

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.