fix(openai): skip realtime truncate when no audio was played

[C1-BA-B1-F3]

Problem

When a RealtimeModel is interrupted in the narrow window after the model has declared an audio response but before the first audio frame is played, the plugin sends a conversation.item.truncate with audio_end_ms=0. The OpenAI Realtime API rejects it:

APIError('Only model output audio messages can be truncated')

Event sequence triggering the bug:

1. response.created
2. response.output_item.added — message_id assigned
3. response.content_part.added — modalities resolve to ["audio", "text"]
4. (user interrupts here — VAD fires) ← response.audio.delta has NOT happened yet
5. Interruption path calls truncate(..., audio_end_ms=0) → server error

Fix

In RealtimeSession.truncate(), when audio_end_ms == 0:

• If the server already holds the (unplayed) item → delete it (prevents dangling items in remote chat ctx)
• If the item was never committed to the server → no-op (nothing to truncate or delete)

When audio_end_ms > 0, behavior is unchanged (truncate event sent as before).

Tests

Three new tests in test_openai_realtime_chat_ctx.py:

1. test_truncate_deletes_item_when_no_audio_played — item on server → delete event
2. test_truncate_noop_when_no_audio_and_item_not_on_server — item not on server → no-op
3. test_truncate_sends_event_when_audio_played — audio_end_ms > 0 → truncate event (regression check)

Fixes #6157

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🚩 Potential stale remote context if update_chat_ctx races with the delete

After truncate() fires a delete event (line 1636-1642), the item remains in _remote_chat_ctx until the server confirms with conversation.item.deleted. If update_chat_ctx (agent_activity.py:3654) runs before that confirmation arrives, its diff computation will still see the item in the remote context. This means it won't try to recreate it — but the server has already deleted it, leaving the remote and local contexts out of sync. In practice this is unlikely to cause user-visible issues because: (1) the update_chat_ctx call at line 3652 requires any_skipped to be true, which is a different condition from the audio_end_ms==0 partial-play scenario; and (2) even if it does occur, the next full update_chat_ctx call would reconcile the difference. Still, this is a potential timing concern worth being aware of.

---

Was this helpful? React with 👍 or 👎 to provide feedback.