Realtime API: history_updated shows in_progress even after response.output_item.done with completed status

[dudududukim]

Describe the bug

history_updated events don't reflect completed status after response.done

The history_updated event, which is automatically managed by the SDK, continues to show status: "in_progress" for assistant messages even after the response has been fully completed (including response.done, output_audio_buffer finished, and response.audio.done).

Debug information

• Agents SDK version: @openai/agents-js (latest)
• Runtime environment: Browser with Realtime API

Repro steps

1. Start a Realtime session and have a conversation with the assistant
2. Observe the following sequence in logs:

   transport response.output_item.added → "status":"in_progress"
   transport response.output_item.done → "status":"completed"  
   transport response.done → "status":"completed"
   // But then:
   history_updated → item still shows "status":"in_progress"
   

Concrete example from logs:

transport response.output_item.done ... "status":"completed" // ✅ Correctly shows completed

// Later:
history_updated [{"itemId":"item_xxxx","type":"message","role":"assistant","status":"in_progress",...}] // ❌ Still shows in_progress

Reproduction Repository

🔗 Complete working example: https://github.com/dudududukim/OpenAI_S2S/tree/main/voice-agent-webrtc

This repository contains full reproduction code demonstrating the bug. Clone the repository and follow the setup instructions to reproduce the issue.

Expected behavior

Since history_updated is automatically managed by the SDK, it should reflect the actual status of items. When response.done is fired after all audio processing is complete, the corresponding item in history_updated should show status: "completed" instead of remaining as status: "in_progress".

Request for OpenAI Team

Please update the history_updated event handling so that it properly reflects the actual completion status of items. Currently, items remain as "status": "in_progress" in history_updated even after they are fully completed (as evidenced by successful audio playback and transcript availability).

The OpenAI team should analyze and determine the appropriate trigger point(s) - whether it's response.output_item.done, output_audio_buffer completion, or other internal completion signals - to ensure history_updated accurately reflects the true item status. Since history_updated is SDK-managed, it should automatically stay synchronized with the actual completion state without requiring developers to manually track status changes.

Additional Context

• This affects all completed assistant responses - they permanently remain as in_progress in history
• The issue persists through multiple conversation turns
• Audio playback completes successfully, transcripts are available, but status never updates in history
• This creates inconsistency between the actual response state and what's reported in the history API

[vrtnis]

Hey @dudududukim - thanks for that detailed repro repo! The right trigger point for updating history_updated is indeed response.output_item.done (currently its the key signal for us to mark it "completed")

However, right now the handler seems to be overriding that servr-provided status with a hard-coded "in_progress". So we just need to preserve whatever the api sends on done (defaulting to "completed" if missing), and also add a safety net of sorts on response.done to promote any leftover "in_progress" items. I think that by handling the status this way, we can clearly separate completion tracking from audio sequencing parts.

output_audio_buffer and response.audio.done will still be respected for audio playback sequencing, but pls note that they don’t change item status on their own, the definitve source remains the output_item.done event. This way, history_updated stays in sync automatically, without us having to track it manually like you said.

The core fix itself to bring history_updated in line with the real item state is straightforward, but it still needs thorough tests added across audio-only flows etc. to make sure edge cases are not missed. Good catch..I'll put together a pr you can try out!

[dudududukim]

Hey @dudududukim - thanks for that detailed repro repo! The right trigger point for updating history_updated is indeed response.output_item.done (currently its the key signal for us to mark it "completed")

However, right now the handler seems to be overriding that servr-provided status with a hard-coded "in_progress". So we just need to preserve whatever the api sends on done (defaulting to "completed" if missing), and also add a safety net of sorts on response.done to promote any leftover "in_progress" items. I think that by handling the status this way, we can clearly separate completion tracking from audio sequencing parts.

output_audio_buffer and response.audio.done will still be respected for audio playback sequencing, but pls note that they don’t change item status on their own, the definitve source remains the output_item.done event. This way, history_updated stays in sync automatically, without us having to track it manually like you said.

The core fix itself to bring history_updated in line with the real item state is straightforward, but it still needs thorough tests added across audio-only flows etc. to make sure edge cases are not missed. Good catch..I'll put together a pr you can try out!

@vrtnis Thank you for the quick response and detailed explanation!

I really appreciate you taking the time to analyze the issue thoroughly. Your clarification about response.output_item.done being the correct trigger point makes perfect sense, and I'm glad the fix is straightforward.

I'd be happy to test the PR when it's ready. I have the complete reproduction environment set up and can provide thorough testing feedback across different scenarios.

Looking forward to helping validate the fix! Thanks for the great work on maintaining this SDK.

[vrtnis]

thanks @dudududukim - here is draft PR #354. would you mind pulling it and trying it out? Would be super helpful to confirm it behaves as expected on your end before finalizing.