Is it possible to bypass the default timeout for Data Actions when executing them via the Architect API under extreme load? We are running a load test from ap-southeast-1 using JMeter 5.6.2 to simulate a sudden spike in concurrent call volumes. The goal is to validate how the platform handles bursty traffic for custom integrations.
The setup involves a simple GET request to an external endpoint wrapped in a Data Action. Under normal conditions (100 concurrent users), the action completes in under 200ms. However, when we ramp up to 2000 concurrent users over a 10-second window, we start seeing a significant number of 504 Gateway Timeout errors returned by the POST /api/v2/data/actions/{actionId}/execute endpoint. The external service logs show that the requests are actually being processed successfully, but Genesys Cloud seems to drop the connection before the response can be mapped back to the Architect flow.
We have tried increasing the timeout setting in the Data Action configuration to 30 seconds, but the 504 errors still appear after just 5 seconds of execution time in the load test. The error payload indicates a platform-level timeout rather than a backend service failure. Given the beginner nature of our load testing setup, we suspect we might be hitting a hidden rate limit or a WebSocket connection cap specific to the data action execution engine.
Are there known limits on the number of concurrent Data Action executions per tenant? The documentation mentions rate limits for API calls, but it is unclear if Data Action executions share the same pool as standard REST API calls. We are seeing this behavior consistently during the ramp-up phase. Any insights on how to tune the JMeter script or if there is a server-side configuration we can request to handle higher concurrency for these specific endpoints would be appreciated. We want to ensure our architecture can handle peak loads without silent failures in data retrieval.