Struggling to figure out why the Message History API is truncating the payload when a conversation routes through a secondary carrier during a failover event.
We are managing 15 BYOC trunks across the Asia/Singapore region, and while voice failover logic is functioning correctly, the digital messaging engagement metrics are desyncing. Specifically, when a conversation initiated on Primary Carrier A fails over to Secondary Carrier B due to a SIP 408 Request Timeout, the subsequent GET /api/v2/conversations/messaging/conversations/{id} call returns a response where the lastActivityDate is correct, but the messages array only contains the initial greeting. The subsequent agent replies and customer responses are missing from the payload entirely. This occurs consistently when the failover happens within the first 15 seconds of the conversation.
We have verified that the SIP registration status remains healthy on both trunks, and the outbound routing configuration in Architect correctly prioritizes Carrier A before falling back to Carrier B. The issue appears to be specific to how the system handles the conversation state transfer during the failover window. The API response includes a standard 200 OK status, but the JSON body lacks the expected message history. We are using the latest version of the Genesys Cloud API client, and the issue persists across all 15 trunks.
Has anyone encountered a similar issue with message history truncation during BYOC trunk failover? We suspect that the conversation state is not being properly synchronized between the primary and secondary carriers, leading to incomplete data retrieval via the API. Any insights into how the system handles message persistence during failover events would be greatly appreciated. We need to ensure that our analytics reporting accurately reflects the full conversation history, regardless of the carrier used.