Quick question about the behavior of the ServiceNow Data Action within a Genesys Cloud Digital Channel flow when handling concurrent updates.
The integration pipeline is currently experiencing a significant rate of failures specifically during peak load periods. The environment is a BYOC deployment in eu-west-2, utilizing Genesys Cloud version 2024-06. The ServiceNow instance is running on the Washington release. The flow is designed to capture incoming digital messages, create a new incident via a webhook, and then update that same incident with transcript data once the conversation concludes.
The issue manifests as a 409 Conflict error from the ServiceNow REST API. The error payload indicates that the record has been modified by another user or process since it was last read. This suggests a race condition where multiple webhooks are attempting to update the same incident record simultaneously, likely due to the asynchronous nature of the transcript generation and the retry logic in the Data Action.
Key environment details:
- Genesys Cloud Region: eu-west-2 (BYOC)
- ServiceNow Version: Washington
- Data Action: Update Incident (Custom REST API)
- Webhook Trigger: Conversation Transcript Available
- Retry Policy: Exponential backoff with 3 retries
I have verified that the sys_updated_on timestamp is being correctly captured and passed in the sys_update header for optimistic locking. However, the latency between the initial webhook trigger and the transcript availability seems to allow for other processes to modify the record, leading to the conflict.
Has anyone encountered similar issues with optimistic locking failures in high-throughput digital channel integrations? Are there specific configuration adjustments in the Data Action or ServiceNow side that can mitigate this, such as disabling optimistic locking for specific fields or implementing a queue-based update mechanism? Any insights on best practices for handling concurrent updates in this context would be greatly appreciated.