What is the reason the Genesys Cloud Agent Scripting API returns a 409 Conflict error specifically when an interaction switches carriers mid-session? We are managing 15 BYOC trunks across APAC and US regions. The primary carrier for our Singapore office has been experiencing intermittent SIP registration drops, triggering our configured failover logic to route traffic to the secondary carrier. This failover works perfectly for voice connectivity, but the analytics and scripting side is breaking down.
When an agent is actively following a script via the Architect flow and the underlying SIP channel fails over, the interaction object updates correctly in the UI. However, any subsequent API call to update the script progress or log a script step via PATCH /api/v2/analytics/reporting/interactions/{interactionId} fails with a 409 status code. The error payload indicates a version mismatch: "message": "The entity has been modified by another process."
We have verified that no other Data Actions or external integrations are touching the interaction at that exact millisecond. The issue seems tied to the internal state transition when Genesys Cloud re-associates the media channel with the new carrier trunk. It appears the interaction’s internal version stamp is not being incremented or synchronized correctly during the carrier switch, causing the optimistic locking mechanism to reject valid updates from the scripting engine.
This is causing significant gaps in our compliance reporting. Agents are unable to mark script steps as complete if the call drops and reconnects via failover. We are using the latest Architect version and have confirmed the scripting flow has the correct permissions. We need a way to handle this race condition or force a refresh of the interaction context before the scripting API is called. How can we programmatically detect the carrier switch event and retry the scripting API call with the correct interaction version to avoid the 409 Conflict?