Why does this setting in the Predictive Routing queue configuration cause a 500 Internal Server Error when assigning agents via the API under high concurrency? I am running a load test to validate the capacity of our US1 environment. The goal is to determine the maximum throughput for agent assignments during peak hours.
The test setup uses JMeter 5.6 with 500 concurrent threads. Each thread attempts to assign a unique agent to a specific routing queue. The API endpoint used is /api/v2/routing/queues/{queueId}/members. The request body includes the memberId and routingProfileId. The routing profile is configured with standard skills and a default priority.
Under low load (50 threads), the assignments succeed with a 204 No Content response. However, when the thread count increases to 500, approximately 40% of the requests fail with a 500 Internal Server Error. The error occurs consistently after the first 100 successful assignments. This suggests a potential locking issue or a timeout within the backend database transaction.
The error response body is minimal and does not provide specific details about the failure reason.
{
"message": "Internal server error",
"code": "server_error",
"status": 500
}
I have checked the API rate limits and confirmed that the request volume is within the allowed threshold for our tenant tier. The WebSocket connections are stable, and there are no network interruptions. The issue seems to be related to the concurrent write operations on the queue membership records.
Is there a known limitation on concurrent queue member assignments? Should I implement a retry mechanism with exponential backoff, or is this a platform-level constraint? Any insights on how to handle these errors during high-volume load tests would be appreciated. The environment details are Genesys Cloud US1, API version v2.2, and the routing queues are configured with standard skill requirements.