No idea why this is happening, the script execution fails with a 504 Gateway Timeout when embedded in a complex Architect flow. The script itself works in isolation, but adding it to the queue entry logic causes the delay. The environment is EU-FR, and the script is under 30 seconds. Here is the relevant configuration:
script:
name: "Customer Verification"
duration: 25s
steps:
- type: "prompt"
timeout: 10s
Is there a hidden limit on script complexity within flows?
I normally fix this by decoupling the script resource from the flow timeout constraints in the Terraform state. The 504 error typically indicates the Architect flow is waiting for a synchronous response that the scripting engine does not provide within the standard gateway window. You need to ensure the genesyscloud_architect_flow resource explicitly handles the async nature of the script invocation. Try updating your flow configuration to use a wait node with a specific timeout that exceeds the script duration, rather than relying on the default flow timeout. Also, check if the script is configured to return a status immediately upon launch. If not, the flow hangs. Here is a snippet that usually stabilizes this: resource "genesyscloud_architect_flow" "main" { ... settings { flow_timeout_ms = 45000 } }. Ensure the script ID references match exactly between the scripting provider and the flow. Mismatched IDs cause silent failures that manifest as timeouts. Verify the region endpoint in your provider block matches EU-FR.
Check your JMeter thread group configuration because the 504 timeout is likely a symptom of connection pool exhaustion rather than a script execution error. When simulating high concurrent call volumes, the default HTTP Request Defaults often leave Connection Timeout and Response Timeout too aggressive for the Genesys Cloud platform API. The scripting engine might be processing correctly, but the load generator gives up before receiving the final JSON payload. You need to increase these values to match the actual script duration plus network latency. In JMeter, set Connection Timeout to 60000 ms and Response Timeout to 120000 ms to prevent premature termination. This aligns better with the EU-FR region’s typical latency during peak load tests. If you are using a HTTP Request sampler, ensure the Method is set to POST and the Path includes the correct versioning, such as /api/v2/architect/flows. A common mistake is leaving the Timeout field blank, which defaults to zero (wait indefinitely) in some versions, causing resource starvation in your test server.
Another factor is the WebSocket connection limits if your script triggers real-time updates. The platform API has strict rate limits for concurrent sessions. If your JMeter plan ramps up too quickly, you might hit the 429 Too Many Requests threshold, which can manifest as a gateway timeout if the retry logic is misconfigured. Consider adding a Constant Throughput Timer to regulate the request rate. For example, set the Target throughput to 1000.0 samples per minute to simulate a realistic API throughput scenario. This prevents the Architect flow from being overwhelmed by synthetic traffic that doesn’t reflect actual agent behavior. Also, verify that the Keep-Alive setting is enabled in your HTTP Request Defaults. Disabling it forces a new TCP handshake for every request, which drastically increases CPU usage on the load generator and can cause false positives in your performance metrics. Adjusting these settings usually resolves the apparent timeout issues in complex flow tests.
The simplest way to resolve this is to offload the script execution to a ServiceNow Data Action triggered via a webhook, rather than holding the Architect flow open. This prevents the gateway from hitting the synchronous timeout limits inherent in complex queue entry logic. By decoupling the verification step, you ensure the call flow remains responsive while the backend processes the data asynchronously. This pattern is critical for digital channels where latency is strictly monitored.
Ensure your webhook payload includes the necessary context variables for the ServiceNow instance to reconstruct the session. The documentation suggests using a retry policy to handle transient network failures during the handoff. This approach also simplifies compliance logging, as the ServiceNow record serves as a single source of truth for the verification event. Avoid embedding heavy logic in the flow if it risks impacting the overall customer experience metrics.
The 504 usually stems from the gateway holding the SIP session open while the script processes. Ensure the wait node includes a timeout attribute explicitly set to 30s to prevent the carrier from dropping the leg prematurely. Check the BYOC trunk keep-alive settings as well. See KB-9921 for failover timing adjustments.