`conversation.messages` and `conversation.entries` always empty - Wrong event name handled

[SergeiMeza]

Description

Both Conversation.messages and Conversation.entries remain empty during conversations, even though the model is responding correctly and audio/transcripts are being received. This is because the SDK is listening for conversationItemCreated events, but OpenAI's Realtime API is actually sending conversationItemAdded events.

Environment

• SDK: swift-realtime-openai (main branch)
• OpenAI Model: gpt-4o-realtime-preview (gpt-realtime-mini)
• Connection Type: WebRTC (using ephemeral key)
• Platform: iOS 26.0

Issue Details

When using the Conversation class, the entries array never gets populated with conversation items because the SDK's event handler has a mismatch between expected and actual event names.

Root Cause

The SDK is listening for the wrong event name.

The SDK handles conversationItemCreated in Conversation.swift:167-168:

case let .conversationItemCreated(_, item, _):
    entries.append(item)

However, OpenAI's Realtime API actually sends conversationItemAdded events instead.

Actual Events Received

The following events ARE received from OpenAI:

• ✅ sessionCreated
• ✅ sessionUpdated
• ✅ conversationItemAdded ← This is the event that should populate entries
• ✅ conversationItemDone
• ✅ responseCreated
• ✅ responseOutputItemAdded ← Also not handled by SDK
• ✅ responseContentPartAdded
• ✅ responseContentPartDone
• ✅ responseAudioTranscriptDelta
• ✅ responseAudioTranscriptDone
• ✅ responseOutputItemDone
• ✅ responseDone

The following events are NOT received (but SDK expects them):

• ❌ conversationItemCreated - SDK listens for this but API sends conversationItemAdded

Additional Notes

• This appears to be a recent change in OpenAI's Realtime API event naming
• The WebRTC connection is working correctly; this is purely an event naming mismatch
• All conversation data is being received, just not being stored in the entries array
• The ServerEvent enum likely already has conversationItemAdded defined but it's not being handled in the switch statement

[jblwilliams]

I also came across this bug. The docs list both events essentially doing the same thing so should be easy to add this into the existing logic to process server sent events. It'd also be nice to add some safety by leveraging previousItemId instead of directly appending in case the events come out of order.

I had to fork to fix some other bugs related to parsing for transcription use cases so will try and submit a PR once that concludes @m1guelpf

[jblwilliams]

Proposed changes here: #56