OpenClaw's realtime voice stack picked up an important reliability repair in PR #121177: failed and incomplete provider responses are now surfaced as visible turn outcomes instead of being treated as success or fatal session errors.
The fix touches realtime Talk, meetings, calls, Discord voice, Gateway relay/control, and browser Talk. It is a large change, but the user-facing behavior is straightforward. A failed voice response should produce one clear failure outcome, and the reusable session should stay alive for the next turn.
The old failure mode
Realtime providers can finish a response with statuses such as completed, cancelled, failed, or incomplete. OpenClaw's hosts were interpreting those terminal events in different places, and some paths inferred success from a generic response.done event.
That caused two bad outcomes:
- A failed or incomplete voice turn could be hidden or look successful.
- A reusable meeting, call, Discord, Gateway relay, or browser session could be closed as if the provider had fatally failed.
There was also an exactly-once problem. Typed providers still emitted a legacy bridge event, so a single response could be finalized twice. If a host callback threw, provider cleanup could also be skipped, leaving queued work stranded.
The new owner
The PR adds an additive RealtimeVoiceResponseOutcome contract on the existing openclaw/plugin-sdk/realtime-voice subpath. OpenAI-style response statuses are normalized into that shared outcome, and providers can emit an optional onResponseDone callback.
RealtimeVoiceSessionHarness becomes the shared terminal owner. It finishes output once, keeps cancellation distinct, marks failed and incomplete turns visibly, suppresses matching legacy bridge events, and fences late response IDs so an old event cannot finish a newer turn.
OpenAI and xAI now emit the typed outcome for every response completion. Failed or incomplete outcomes no longer flow through session-fatal error handling, and provider cleanup/draining happens in finally so queued responses can continue even if a callback fails.
Where users will notice
This is most visible in long-lived audio sessions:
- OpenClaw Talk sessions can report the provider reason and continue.
- Meeting agents in Google Meet, Teams, and Zoom keep the reusable bridge alive.
- Discord voice and voice-call integrations avoid closing the whole session for one failed response.
- Browser Talk and Gateway relay/control now share the same terminal policy.
The PR's evidence includes focused SDK, OpenAI, xAI, meeting, Voice Call, Gateway relay/control, browser WebRTC, and Discord voice test suites, plus exact-head hosted CI.
A cleaner realtime contract
The deeper win is that OpenClaw now has one typed place to decide what a realtime response meant. That should make future provider work less error-prone, especially as realtime voice expands across meetings, calls, browser sessions, and channel integrations.
For anyone using OpenClaw as a live voice assistant, the practical result is calmer recovery: a bad turn is reported as a bad turn, not mistaken for success and not allowed to take down the conversation.