respond() intermittently never returns after parallel tool calls

Aberta
  • Algo errado?
#21 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
28/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
ai

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
1.4k
Forks
89
Merge médio
1min
PRs com merge (30d)
1

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apple/python-apple-fm-sdk

Todas as issues de apple/python-apple-fm-sdk

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.