Dealing with a very strange bug here with our custom Data Action script designed to validate SIP registration states across our 15 BYOC trunks in the ap-southeast-1 region. The script executes a parallel HTTP POST to the v2/trunking/locations endpoint to fetch current trunk status, followed by a series of curl commands against our carrier’s provisioning API to verify credential validity. While the Genesys Cloud API calls complete within 200ms, the subsequent carrier API calls consistently trigger a 408 Request Timeout from the Genesys platform after exactly 15 seconds, despite the carrier responding in under 500ms. The error payload indicates timeout_exceeded at the edge gateway level. We have verified that the outbound IP ranges for ap-southeast-1 are whitelisted on the carrier side, and direct testing from a bastion host in the same region shows no latency. The issue appears isolated to Data Action execution contexts, suggesting potential TCP connection pooling limits or strict egress firewall rules applied to the scripting runtime environment. We are using the latest Architect flow version (v4.2.1) and have increased the timeout threshold in the Data Action configuration to 30 seconds, but the 408 persists. The logs show the request drops immediately after the initial SYN-ACK handshake with the carrier endpoint. This is disrupting our automated failover logic, as we rely on this script to flag trunks with stale credentials before routing critical outbound campaigns. We need to understand if there is a hidden concurrency limit for external HTTP calls initiated from Data Actions in this specific region, or if the egress traffic is being inspected and dropped due to payload size or header anomalies. The SIP credentials are rotated daily, and the script handles the JSON parsing correctly in local tests. Any insights into the network path or runtime constraints for ap-southeast-1 Data Actions would be appreciated. Is there a known issue with long-lived TCP connections in this environment?
The main issue here is likely external latency triggering the Data Action timeout. Genesys defaults to 5000ms. Increase timeout_ms in genesyscloud_flow_action_data_action. Do not exceed 10000ms or Architect will kill the flow. Consider moving carrier checks to an async webhook instead.