Realtime: a context copied while a text turn's push is in flight omits the user message, and the next update deletes it from the server
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
Research direction
Start at voice/agent_activity.py around _realtime_reply_task and compare the text-turn ordering with the two tool-output paths near lines 4759–4808. Use the delayed-acknowledgement reproduction with openai.realtime.RealtimeModel to confirm that a copied context lacks the user message and later deletes it. Done means the context contains the message while its push is in flight, and the chosen behavior for push failures preserves consistency without leaving an invalid local turn.
Written by the indexing model from the issue text.
Description
Bug Description
With a realtime model, a text user turn adds its user message to the agent's own chat context only after its push to the server returns. While that push is in flight, agent.chat_ctx does not contain the message, so anything that copies the context in that window produces a context that is missing an item the server is about to acknowledge — and the next diff deletes it from the server conversation.
_realtime_reply_task, livekit-agents 1.8.8, voice/agent_activity.py:
msg = chat_ctx.add_message(role="user", content=user_input) # on a copy of the mirror
try:
await self._rt_session.update_chat_ctx(chat_ctx) # :4164 the push
except ...
self._agent._chat_ctx._upsert_item(msg) # :4198 only now is it local
self._session._conversation_item_added(msg)
The interleaving:
- The text turn pushes
helloand waits for the server to acknowledge it. - Application code calls
session.update_chat_ctx(agent.chat_ctx.copy()). That copy has nohelloin it, because of the ordering above.AgentActivity.update_chat_ctxassignsself._agent._chat_ctx = chat_ctximmediately and then callsRealtimeSession.update_chat_ctx, which blocks on the plugin's_update_chat_ctx_lock. - The text turn's ack lands, the mirror now contains
hello, and the turn upserts it locally. - The replacement acquires the plugin lock and diffs its own context object — still without
hello— against a mirror that has it.helloappears into_remove, so aconversation.item.deletegoes out for it.
The local context keeps the message and the server conversation loses it, so the reply is generated without the user's turn.
Both tool-output paths already do this the other way round — self._agent._chat_ctx.insert(interrupted_fnc_outputs) at :4759 and the two _upsert_item calls at :4807-4808 run before their pushes, so a context copied mid-push contains those items and no diff can delete them. The text turn at :4198 is the only push that updates the local context after the fact.
This is not the same race as #7880 (overlapping pushes diffing stale snapshots of the server mirror, fixed by serializing snapshot and push in #7904 / #7905). Serializing does not help here: the replacement's context object is captured before it blocks, and no ordering of the pushes refreshes it.
Expected Behavior
A context copied from agent.chat_ctx while a text turn's push is in flight contains that user message, so a replacement push cannot delete an item the server is about to acknowledge. The agent's context and the server conversation stay in agreement.
Reproduction Steps
# Needs a provider whose update_chat_ctx diffs against an acknowledged mirror
# (the OpenAI realtime plugin) and a non-instant ack, so there is a window:
1. AgentSession with openai.realtime.RealtimeModel and a realtime provider that acks after ~50 ms.
2. session.generate_reply(user_input="hello") — the push at agent_activity.py:4164 is now in flight.
3. Before it returns, from another task: await session.update_chat_ctx(session.current_agent.chat_ctx.copy())
4. Watch the client events: after the conversation.item.create for the user message is acked,
the replacement sends conversation.item.delete for that same item.
5. The reply is generated from a server conversation with no user turn.
# With an instant ack there is no window and step 4 does not happen.
Possible fix
Hoisting self._agent._chat_ctx._upsert_item(msg) above the push makes the text turn consistent with the two tool-output paths, and is one line. It is not free, so it is worth deciding deliberately rather than just moving it:
_conversation_item_addedis emitted from the same place, so hoisting changes when that event fires relative to the push.- On the unexpected-exception path the turn currently returns without recording the message at all (
speech_handle._mark_done(error=e); return). Hoisting would leave it in the local context for a turn that failed, unless it is removed there.
Happy to send a PR once there is a view on which of those two behaviours should win.
Operating System
Linux and Windows (read from the source; the window depends only on ack latency)
Models Used
OpenAI Realtime via openai.realtime.RealtimeModel; any realtime provider that diffs against an acknowledged server mirror
Package Versions
livekit-agents==1.8.8
# the ordering at agent_activity.py:4198 is the same on main at ceb3d598f
Session/Room/Call IDs
None: found while fixing #7880.
- Dominant language
- Python
- Stars
- 14.6k
- Forks
- 3.9k
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 165
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from livekit/agents
-
Agent state stays "speaking" after a realtime reply in sessions without audio outputPossibly taken @Luke-salinero claimed this 2 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Assistant markup is stripped from chat history when expressive mode is offPossibly taken @ShivamSharma43 claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
docs: openai.LLM vs openai.responses.LLM for HTTP OpenAI-compat hostsMay be free again @AbarnaaSree claimed this 50 days ago, and no pull request is open. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
livekit/agents#7022 · 1 comment ·
Maintainers usually reply within 1 day
-
Anthropic plugin drops thinking blocks between tool callsPossibly taken @Yatha04 claimed this 1 day ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
SpeakingRateStream blocks the event loop: per-frame Python STFT loop in `_stft` / `_spectral_flux`Possibly taken @omerekin claimed this 1 day ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
Similar issues
-
documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
drevendev/HungryCrab#273 ·
Maintainers usually reply within 1 day
-
good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
drevendev/BeautifulRepo#19 ·
Maintainers usually reply within 2 days
-
Moonshot: Kimi K3 always sends `reasoning_effort="max"`, though the API now accepts `low` and `high`Openaccepted
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
UKGovernmentBEIS/inspect_ai#5939 ·
Maintainers usually reply within 1 day
-
bug linux
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
area:data data-quality
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
reacher-z/Awesome-CUA#1468 ·
Maintainers usually reply within 1 day