respond() intermittently never returns after parallel tool calls

Ouverte
  • Quelque chose ne va pas ?
#21 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
28/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
ai

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
1.4k
Forks
86
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apple/python-apple-fm-sdk

Toutes les issues de apple/python-apple-fm-sdk

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.