Dealing with a very strange bug here with our outbound routing logic when trying to dynamically adjust IVR paths based on real-time carrier latency metrics. We manage fifteen BYOC trunks across AP-Southeast-1 and AP-South-1, and our standard practice involves using Data Actions within the Architect flow to fetch recent call quality stats before initiating the SIP INVITE.
The specific issue arises when the Architect flow attempts to execute a Data Action that calls the GET /api/v2/analytics/details/summary endpoint with a filter for the last 5 minutes of trunk activity. Instead of returning the expected JSON payload, the flow hangs for approximately 12 seconds before throwing a generic timeout error. This delay is unacceptable for our low-latency routing requirements.
We have verified that the API credentials used in the Data Action configuration have the necessary analytics:read permissions. Direct calls to this endpoint from Postman using the same access token succeed instantly. The problem seems isolated to the execution context within the Architect environment.
Here is the error log captured from the Architect flow trace:
{
"error": "DataActionTimeout",
"message": "The data action 'GetTrunkLatency' exceeded the maximum execution time of 10000ms.",
"errorCode": "GENESYS_CLOUD_2045",
"details": "Upstream service did not respond within the allocated window."
}
We are currently on Genesys Cloud version 23.12.0. The BYOC trunks are registered via SIP 2.0 with TLS 1.3. We suspect there might be a network path issue between the Architect execution engine and the analytics reporting service in the AP-Southeast-1 region, or perhaps a rate-limiting mechanism that is not documented.
Has anyone encountered similar latency spikes when integrating BYOC analytics directly into routing logic? We need a reliable way to fetch these metrics without introducing significant call setup delays.