OpenClaw Hardens Realtime Voice Against Stale Sessions and Transcript Growth
Google startup queue and readiness fixes extend OpenClaw’s merged realtime protections against stale sessions, dropped input and runaway memory growth.
OpenClaw has merged a coordinated set of realtime voice fixes covering several ownership failures: xAI sessions could retain queued input after terminal close, Google Live connection attempts could outlive the session that created them, meeting-bot playback could grow memory when an audio sink stalled, and Google or Mistral could retain an unbounded in-progress transcript when a provider never finalized the segment.
These are source changes on main, not evidence that a particular package includes them. Operators using realtime voice should identify a containing revision and test their actual provider, playback host and interruption path before relying on the corrections.
The common failure: work outlived its owner
Realtime audio is a pipeline of concurrent owners: provider session, connection attempt, model response, output generation, playback sink and user call or meeting. A close, reconnect, barge-in or replacement response must invalidate every piece of queued work that belongs to the old generation.
The four merges address different points in that chain:
| Surface | Failure addressed | New boundary |
|---|---|---|
| xAI realtime | Audio, user messages and tool results could remain queued after close or terminal reconnect failure | Terminal close clears bounded queues and resumable state; late input is rejected until explicit reconnect |
| Google Live | A late provider session or callback from an abandoned connection could mutate a replacement session | Connection attempts have ownership; concurrent connects share the intended provider session |
| Meeting bot | A stalled local or node playback sink could retain unbounded realtime audio | Egress is bounded and serialized; clear, stop, barge-in and terminal events invalidate old output generations |
| Realtime transcription | Evicting microphone frames during a prolonged provider connection stall could become progressively slower as backlog grew | Queue eviction advances a head and periodically compacts retained storage instead of shifting the full array for every dropped frame |
| Google Live transcript | Missing finished markers could leave per-role pending transcript text growing and repeatedly copied |
Each role has an independent 256 KiB UTF-8 pending budget; overflow clears pending state and terminates safely |
| Mistral transcript | Endless deltas without segment finalization could retain and copy an unbounded partial transcript | The current partial has a 256 KiB UTF-8 budget that clears on finalization; overflow becomes terminal |
| Google Live startup | Setup completion could race the usable session, stranding the first audio or greeting; prompts queued during lazy startup could be dropped or grow without bound | Readiness requires the usable session owner, then flushes a pre-ready queue capped at 128 messages and 256 KiB of UTF-8 text |
Interpretation: queue length alone is not a sufficient safety control. Every queued item also needs an owner and a terminal event that makes stale work impossible to deliver.
xAI: close now means the input surface is closed
PR #116659 covers audio, user messages and tool results submitted around terminal failure. Upstream says pending audio is bounded by both bytes and chunks, oversized input is rejected before copying, and queued Buffer views are copied so a small slice does not retain a much larger backing allocation.
The fix also clears resumable state, including the conversation identity, at terminal boundaries. Input arriving after close is rejected until an explicit reconnect establishes a new owner.
That last rule matters. Clearing a queue but leaving the producer able to refill it after close merely turns one leak into a recurring one.
Google Live: late setup cannot take over a replacement
PR #116493 handles close or restart while provider setup is still in flight. A connection promise may resolve after the user has already closed the session or started a replacement. Without attempt ownership, that late result can install stale provider state or allow callbacks from the abandoned connection to mutate the new one.
The merged path assigns ownership to the connection attempt and makes concurrent connect() calls share the intended provider session rather than opening several. Operators should specifically test close-during-connect, because a steady-state call does not exercise this race.
Meeting bot: playback pressure must travel upstream
PR #116589 bounds and serializes realtime audio egress. It adds response ownership and generation fencing so clear, stop, barge-in and provider terminal events invalidate audio queued for an older response.
The change also accounts for mixed node-host capability: newer hosts can negotiate output generations, while legacy paths retain serialized compatibility behaviour. That is an upgrade consideration for split deployments. A current Gateway talking to an older playback node must remain bounded and ordered even if the node cannot participate in the newest fencing contract.
Backpressure is not only a memory issue. If old audio remains deliverable after a human interrupts, the system can speak a superseded response over the next turn. Bounding storage without invalidating ownership would cap the leak but preserve the conversational error.
Transcription: a bounded queue still needs a bounded hot path
PR #116935, merged later on July 31, fixes a separate realtime transcription slowdown during prolonged provider connect or reconnect stalls. The queue already needed to discard old microphone frames under backlog, but removing each frame by shifting the full retained array made repeated eviction quadratic.
The merged path advances a queue head and periodically compacts storage instead. That preserves the backlog policy while avoiding a full-array move for every dropped frame.
Interpretation: a memory bound is not enough if enforcing it consumes progressively more CPU. Under provider failure, the overload-control path itself must remain cheap or it can delay recovery and starve unrelated session work.
Add a sustained connect-stall fixture to the acceptance run. Hold the provider boundary closed, feed synthetic frames beyond the queue limit, and confirm retained memory stays bounded without eviction time growing with every discarded frame. Do not use a live microphone or sensitive audio for this test.
Google and Mistral now bound unfinished transcript text
PRs #117179 and #117190, merged on August 1, address a second kind of realtime accumulation. A provider can continue emitting transcript deltas without sending the protocol marker that finalizes the current segment. The session then retains and repeatedly copies an ever-growing partial string even though audio-frame queues may already be bounded.
Both adapters now enforce a 256 KiB UTF-8 budget for pending transcript state. Google keeps independent budgets per role; Mistral owns the budget for its current partial segment and clears it on finalization. The official records describe overflow as terminal rather than silently truncating and continuing.
That failure direction matters. Silent truncation could produce a plausible but incomplete transcript while the session continues making decisions from different context. A terminal overflow is visible and prevents the unbounded copy loop, though operators still need to decide how the surrounding call or meeting should recover.
Test with synthetic text and a provider fixture that deliberately withholds finalization. Confirm retained transcript bytes stay bounded, overflow ends the affected path visibly, no partial text is later presented as a complete segment, and a new session starts with an empty pending budget.
Google startup now owns both readiness and queued prompts
PR #117450 fixes a race in which Google could report setup completion before returning the usable realtime session. The bridge could appear ready while the first queued audio or greeting remained stranded. The merged path activates only after the socket, setup completion and intended provider-session ownership agree.
PR #117529 closes the adjacent lazy-start boundary. Text prompts submitted while the provider is still connecting now enter a pre-ready queue capped at 128 messages and 256 KiB of UTF-8 text. The queue flushes when the authoritative provider session becomes ready; close wins over a late ready callback.
Those are complementary controls. Readiness ownership prevents delivery to a session that cannot yet consume input, while queue bounds prevent waiting input from becoming an unbounded memory store. Operators should test both a normal first prompt and deliberate overflow. The expected overflow or refusal must be visible; do not infer delivery from a connected UI indicator.
Who should prioritise this
- operators running xAI or Google realtime providers;
- Google Meet or other meeting-bot deployments using local or node playback;
- long-running voice sessions where network stalls are routine;
- mixed-version Gateway/node fleets;
- environments that allow tool results to feed an active realtime provider; and
- teams monitoring process memory but not queue ownership or stale output.
The right response is not to move production directly to an arbitrary main snapshot. Find the first containing release, stage it with your provider credentials and use synthetic audio plus non-sensitive tool output.
Acceptance test
For each enabled realtime path:
- establish a test session and record its opaque session identity;
- stall playback or provider setup using a reversible fixture;
- send bounded synthetic audio and a harmless user event;
- close, barge in or replace the response while work remains queued;
- confirm memory and queue depth stop growing;
- confirm old audio never plays after the terminal event;
- confirm late callbacks cannot mutate the replacement session;
- confirm post-close input rejects until explicit reconnect;
- reconnect and prove the new session accepts fresh input exactly once; and
- withhold transcript finalization while feeding synthetic deltas beyond 256 KiB and prove overflow is terminal and bounded; and
- submit Google prompts before provider readiness, prove they flush once in order, and verify the queue stays within 128 messages and 256 KiB; and
- repeat with the oldest supported node host in a mixed-version deployment.
Set observation limits before the test. Do not create an uncontrolled live denial of service merely to prove a bound exists.
Incident response
If a voice process has unexplained growth or stale playback, preserve redacted queue metrics, provider connection timelines, close/reconnect events and Gateway/node versions. Terminate the affected session through supported controls, then verify provider and media sockets actually close.
Do not dump raw audio, user text or tool results into a general incident ticket. Those queues may contain sensitive meeting or call content. Prefer counts, byte sizes, opaque IDs and carefully redacted timing evidence.
Evidence and limits
The official PR records and issue relationship agree on the lifecycle and backpressure failures. Earlier source verification surfaced the xAI queue bounds, Google connection ownership and meeting-bot generation fencing; later collector records establish the transcription queue-head change, the Google/Mistral pending-transcript budgets, Google readiness ownership and the bounded pre-ready prompt queue. Direct GitHub extraction was unavailable for the latest merges, and OpenClaw Academy did not run live provider calls or reproduce their stress tests.
The packet also contains adjacent Discord, voice-call and WebSocket lifecycle fixes. They reinforce the same ownership theme but are not treated here as proof for the three provider paths analysed above.
Bottom line
Realtime voice reliability depends on terminal ownership, not just a connected socket. Closed sessions must reject late input, abandoned connection attempts must lose authority, and stalled playback must be both bounded and invalidated when the conversation moves on.
Adopt a containing build through staged change control, then test close-during-connect, barge-in under backlog and mixed-version playback. A successful clean call proves almost none of the failure boundaries these merges were written to repair.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.- 01Prevent closed xAI realtime sessions retaining input — PR #116659↗
- 02Prevent stale Google realtime sessions after close — PR #116493↗
- 03Bound stalled meeting-bot realtime playback — PR #116589↗
- 04Prevent queued transcription slowdown under backlog — PR #116935↗
- 05Realtime voice provider and consult state tracking — issue #116201↗
- 06Bound Google Live pending transcripts — PR #117179↗
- 07Bound Mistral realtime pending transcripts — PR #117190↗
- 08Avoid dropping the first Google realtime voice input — PR #117450↗
- 09Preserve Google realtime prompts during startup — PR #117529↗
THE OPERATOR BRIEF