respond() intermittently never returns after parallel tool calls

Đang mở
  • Có gì không ổn?
#21 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
28/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
ai

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
1.4k
Fork
89
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apple/python-apple-fm-sdk

Tất cả issue của apple/python-apple-fm-sdk

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.