Architect v2024.3.1 handles the inbound routing through a standard transfer node, but the custom Data Action step keeps dropping the ball when the Ohio BYOC pool swaps in. Primary trunk is live and breathing. SIP registrations stay solid across all 15 carriers. Once the health check flips and the failover logic kicks, the flow jumps to the credential lookup node. Console throws a DATA_ACTION_TIMEOUT after exactly 15 seconds. The internal endpoint is just a simple GET to /api/v2/routing/carriers/active?region=ohio. Returns a 200 with the JSON payload in under 200ms when hit directly from Postman. Flow node just sits there doing jack all.
Flow config has the timeout set to 20s, so it shouldn’t cut off early. Retry logic is disabled for now since it just loops the timeout anyway. SIP proxy logs show the INVITE hitting the Ohio gateway without issue, but the media stream never gets the auth headers because the data action doesn’t resolve. Eastern peak hours make this worse. Traffic spikes hit around 10 AM, and the routing table gets hammered.
Tried bumping the timeout to 30s. Changed the HTTP method to POST just to rule out cache headers. Swapped the endpoint to a cached CDN version. Same result. The node stays yellow in Architect, then red. No payload in the debug logs, just the timeout error.
{
"errorCode": "DATA_ACTION_TIMEOUT",
"message": "Request exceeded maximum execution time",
"flowId": "a8f3c2d1-99e4-4b2a-8c7d-11f3e9a0b4c2",
"nodeId": "credential_lookup_ohio",
"timestamp": "2024-09-14T14:32:08.112Z"
}
Carrier A and Carrier B both hit the same wall. Routing rules are identical across regions, so it’s not a config mismatch. The proxy just waits for the data action to resolve before attaching the SIP headers. Debug trace shows the request actually leaves the Genesys edge but never gets the ACK back. Looks like a TLS handshake stall on the outbound connector. Certificate chain on the data action proxy might be…
The 15-second timeout is the default limit for Genesys Cloud Data Actions. Your internal endpoint is likely taking longer than that during the failover handoff, or the connection is stalling while the Ohio pool initializes. You need to increase the timeout value in the Data Action configuration to give the carrier credential fetch enough breathing room.
In Architect, select the Data Action node. Look for the Timeout field in the properties panel. Change it from 15000 (milliseconds) to something like 30000 or 60000. This gives your backend service more time to respond without the platform cutting it off.
Here is how you can also verify the actual response time using a simple curl command against your internal endpoint to see if it’s consistently hanging:
curl -w "\nTime Total: %{time_total}s\n" -o /dev/null -s "https://your-internal-endpoint.com/api/v1/carrier-credentials?pool=ohio-byoc"
If the Time Total is regularly exceeding 15 seconds, increasing the Architect timeout is the only fix. If it’s under 15 seconds but still timing out, check your network path. The Ohio BYOC pool might be routing through a different VPC or subnet that has stricter firewall rules or higher latency to your internal API.
Also, ensure your internal service is returning a 200 OK with a valid JSON payload immediately. If it’s sending chunked responses or keeping the connection open longer than necessary, Genesys might drop it. Keep the response body small. Just the credentials. No extra metadata.
One more thing: check if your internal endpoint requires any specific headers for authentication that might be missing during the failover state. Sometimes the context passed to the Data Action changes slightly when the pool swaps. Add logging to your internal service to capture the exact request headers it receives during the failover event. Compare them to the happy path.
If the issue persists after increasing the timeout, consider adding a retry logic in your internal service instead of relying on the Data Action to retry. Genesys doesn’t automatically retry failed Data Actions in the middle of a flow. You’d have to route to an error handling branch and loop back, which adds complexity. Better to fix the root cause of the delay.
Check your internal service logs for any database connection timeouts or slow queries triggered by the Ohio pool ID. That’s usually where the bottleneck hides.