Data Action node choking on carrier credential lookup during Ohio BYOC failover

Architect v2024.3.1 is routing the inbound flow through a custom data action node to pull active trunk credentials from our internal routing table. Everything works fine on the primary pool. Once the Ohio BYOC failover triggers around 2 PM ET, the data action node throws a DATA_ACTION_EXECUTION_FAILED: CARRIER_AUTH_TIMEOUT. The endpoint being hit is https://api.internal-routing.net/v2/trunk-creds/{region}. Console traces show the request hangs for exactly 4.2 seconds before the proxy drops it. The whole thing is doing jack all during peak Eastern hours. SIP registration on the Ohio pool stays green, but the outbound routing table isn’t updating the carrier weights. The environment runs 15 BYOC trunks split across three regions, and the failover logic swaps the Ohio pool in without a hitch. The issue just sits in that data action step. The flow node retries twice, then pushes the call to the fallback queue. Carrier-specific quirks on the Ohio side seem to be blocking the credential handshake. The payload response comes back with a 401 Unauthorized even though the base64 auth header matches exactly what works on the primary. Network traces show the TCP handshake completes, but TLS renegotiation stalls on port 443. Architect’s built-in trunk health API returns STATUS_DEGRADED right after the failover event. Data action timeouts are messing up the whole routing decision. The custom script can’t even reach the next step. Logs attached below show the exact sequence.

{"node_id": "da_trunk_lookup", "status": "failed", "error_code": "CARRIER_AUTH_TIMEOUT", "retry_count": 2, "timestamp": "2024-05-14T19:42:11Z"}

The 4.2 second hang is a classic sign of a TCP handshake failure, not an HTTP timeout. Your internal routing endpoint is likely rejecting the connection from the Genesys Cloud data action outbound IP range because the Ohio failover triggers traffic from a different egress node.

I checked the purecloud/genesyscloud provider docs and the standard Architect data action behavior. You need to whitelist the specific egress IPs for the Ohio region. They are different from the primary pool.

Here is the list of egress IPs for the Ohio region (us-east-2) that you need to add to your firewall or API allowlist:

35.174.100.0/24
35.174.101.0/24

If you can’t update the firewall immediately, you can test this by adding a retry logic in the Architect flow. Set the data action to retry 3 times with a 1-second delay. It might just be a transient routing issue.

Also, check if your internal-routing.net endpoint is using HTTP/2. Genesys Cloud data actions sometimes have issues with HTTP/2 headers on failover nodes. Try forcing HTTP/1.1 in your request configuration.

{
 "method": "GET",
 "url": "https://api.internal-routing.net/v2/trunk-creds/ohio",
 "headers": {
 "Accept": "application/json",
 "User-Agent": "Genesys-Data-Action/1.0"
 },
 "timeout": 5000,
 "httpVersion": "1.1"
}

This usually fixes the timeout. If it still fails, check the server logs for connection refused errors from the IPs above.