Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Finished tool call is dropped when a parallel tool's guardrail trips

Đã đóng
  • Có gì không ổn?
#5,327 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Một pull request liên quan đã được merge.

  • #5332 của @jbeckwith-oai — đã merge

Đá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
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
python
Lĩnh vực
backend-api-design

Hướng nghiên cứu

The report includes a complete ScriptedModel repro but does not name implementation or test files. Start by running the repro and tracing how parallel tool results are handled when the batch raises; check how run_data, session state, and input-list conversion retain completed calls and preceding reasoning items. Done means the run still raises while completed calls remain available to the next turn; an open pull request is already linked.

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

Mô tả

Please read this first
  • Have you read the docs? Yes.
  • Have you searched for related issues? Yes. #4125 and #5318 fixed similar losses, but this case still happens on main.
Describe the bug

When parallel tool calls run and one of them ends the run with an exception, a call that already finished is dropped from the history.

For example, the model calls create_ticket and send_email together. create_ticket finishes. Then a tool input guardrail on send_email trips, and the run raises ToolInputGuardrailTripwireTriggered. The Session ends up with only the user message, so on the next turn the model creates the ticket again. gpt-5-mini did this 10 of 10 times. With a fix, it was 0 of 10.

The input was accepted and create_ticket really ran, so this isn't speculative work. The guardrails docs keep "already-completed tool call and tool output items" when an output guardrail trips. The same loss also happens with a tool output guardrail, with failure_error_function=None, and when on_tool_end raises.

A fix that worked for me: when the tool batch raises, record the outputs of calls that already finished before re-raising, and keep any reasoning item that comes before a kept call.

Debug information
  • Agents SDK version: 0.23.1, and main at 71c2da4d
  • Python 3.12.13, macOS 15.6.1, openai 3.24.0
  • Model: none, the repro uses ScriptedModel
  • Reproduces on the latest release, every time
Repro steps
import asyncio

from agents import (Agent, RunHooks, Runner, SQLiteSession, ToolGuardrailFunctionOutput,
                    function_tool, set_tracing_disabled, tool_input_guardrail)
from agents.testing import ScriptedModel, assistant_message, function_call

ticket_created = asyncio.Event()


@function_tool
def create_ticket(order_id: str) -> str:
    return f"ticket T-1 for {order_id}"  # The ticket now exists.


@tool_input_guardrail
async def block_email(data) -> ToolGuardrailFunctionOutput:
    await ticket_created.wait()  # Trip only after create_ticket has finished.
    return ToolGuardrailFunctionOutput.raise_exception(output_info="blocked")


@function_tool(tool_input_guardrails=[block_email])
def send_email(order_id: str) -> str:
    return "sent"


class Hooks(RunHooks):
    async def on_tool_end(self, context, agent, tool, result) -> None:
        ticket_created.set()


def show(items: list) -> list[str]:
    return [f"{i['type']}:{i['call_id']}" if "call_id" in i else i.get("role", "?") for i in items]


async def main() -> None:
    calls = [function_call(n, {"order_id": "A1"}, call_id=f"call_{n}") for n in ("send_email", "create_ticket")]
    model = ScriptedModel([calls, [assistant_message("ok")]])
    agent = Agent(name="support", model=model, tools=[send_email, create_ticket])
    session = SQLiteSession("demo")
    try:
        await Runner.run(agent, "Open a ticket for order A1 and email the customer.", session=session, hooks=Hooks())
    except Exception as exc:
        print("raised:      ", type(exc).__name__, "| run_data.new_items:", len(exc.run_data.new_items))
    print("session:     ", show(await session.get_items()))
    await Runner.run(agent, "Please finish the task.", session=session)
    print("next request:", show(model.last_call.input))


set_tracing_disabled(True)
asyncio.run(main())

Output on 0.23.1 and on main:

raised:       ToolInputGuardrailTripwireTriggered | run_data.new_items: 0
session:      ['user']
next request: ['user', 'user']
Expected behavior

The run still raises, but the finished call stays in the Session, run_data, to_input_list() and to_state(), so the next turn sees it:

raised:       ToolInputGuardrailTripwireTriggered | run_data.new_items: 2
session:      ['user', 'function_call:call_create_ticket', 'function_call_output:call_create_ticket']
next request: ['user', 'function_call:call_create_ticket', 'function_call_output:call_create_ticket', 'user']

A reasoning item before a kept call has to stay too, or the Responses API rejects the next request.

I ran the repro on 0.23.1 and on main.

Ngôn ngữ chính
Python
Star
30k
Fork
4.9k
Merge trung bình
15 giờ 43 phút
Pull request đã merge (30 ngày)
211

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

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 openai/openai-agents-python

Tất cả issue của openai/openai-agents-python

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.