A realtime transcript can contain the right words and still make the conversation history wrong—if those words land on the wrong user turn.
The Pydantic AI v2.46.0 release notes list a bug fix: “Keep late realtime input transcripts attached to the user turn they belong to,” linking PR #8139. For engineers using Pydantic AI realtime sessions, that is a concrete reason to check turn attribution before treating recorded dialogue as reliable input for review or continuation.
Arrival order is not ownership
Consider a hypothetical session:
- Turn A: “Send it to the office.”
- Turn B: “Actually, send it home.”
- A’s transcript arrives only after B already exists in the history.
If the history handler attaches that late text to the newest user turn, the recorded correction can become misleading even though A’s transcription is accurate. This is the engineering implication of the reported fix, not a reproduced incident or an ASR accuracy result.
The useful invariant is simple: late text must update its originating turn, not whichever turn happens to be newest when it arrives.
A regression case worth requiring
I would make the following an application-level acceptance test when evaluating the fix. A and B here are conceptual labels, not Pydantic AI API fields.
- Create two distinguishable user turns, A and B, while holding back A’s input transcript in the test harness.
- Let B exist with its own transcript, then capture B’s identity, text and position in the conversation history.
- Deliver A’s delayed transcript through the history-handling path under test.
- Assert that A now contains A’s text and that B’s identity, text and position are unchanged. Check for a duplicate or misplaced A entry as well as an overwritten B.
- Repeat with ordinary in-order transcript delivery. The transcript-to-turn associations should match, despite the different arrival order.
Inspect the history representation your application actually uses for review or continuation—not just a transcript callback log. These are proposed checks; they were not run here and are not a description of the upstream test suite.
For an upgrade decision, include v2.46.0’s reported fix in your evaluation, but use the delayed-transcript case as the acceptance criterion. A version number alone cannot verify your application’s history handling. If attribution still fails, investigate the library/application boundary before treating that history as trustworthy; the failure alone does not identify which layer is responsible.
What this fix does not prove
The cited release-note entry does not specify the attribution mechanism, affected prior-version range, provider coverage or completeness of testing. The linked PR and implementation are outside the evidence used here. Nor does this entry establish better recognition accuracy, lower latency, improved interruption handling, durable persistence or a retention guarantee.
The narrow decision is whether your stored dialogue preserves who said what in which turn when transcripts arrive late. That deserves its own assertion, separate from whether the words sound correct.