Error 504 Gateway Timeout on POST /api/v2/integrations/dataactions/{id}/invocations. The Data Action queries trunk status for 15 BYOC connections; latency spikes when checking failover states across regions. Architect flow halts indefinitely after this step. How do I optimize the data action payload or timeout settings to handle concurrent trunk status checks without dropping the connection?
The root of the issue is likely that the Data Action payload is attempting synchronous, serial HTTP calls to the Genesys Cloud API for each BYOC trunk. The API gateway drops connections after 30 seconds by default, which is insufficient for 15 concurrent region checks if they are not batched correctly.
Error 504 Gateway Timeout on POST /api/v2/integrations/dataactions/{id}/invocations
To fix this, you need to refactor the Data Action script to use asynchronous promises or batch the requests. If you are using a custom script action, ensure the timeout property in the resource definition is increased. The default is often too low for multi-region latency.
Here is the Terraform configuration to increase the timeout limit on the Data Action resource:
resource "genesyscloud_routing_data_action" "byoc_status_check" {
name = "BYOC Trunk Status Check"
description = "Checks status of 15 BYOC trunks"
# Increase timeout to 60 seconds to handle regional latency
timeout = 60000
script {
type = "custom"
code = <<EOT
// Use Promise.all for parallel execution instead of sequential loops
const trunkIds = input.trunkIds;
const results = await Promise.all(
trunkIds.map(async (id) => {
try {
const res = await httpClient.get(`/api/v2/telephony/providers/edges/trunks/${id}`);
return { id, status: res.body.status };
} catch (err) {
return { id, status: 'error', message: err.message };
}
})
);
return { results };
EOT
}
}
Also, verify the genesyscloud_routing_data_action provider version. Older versions had bugs with large payload serialization. Updating to v1.12.0+ helps with JSON parsing stability. If the flow still hangs, consider splitting the 15 trunks into two separate Data Actions triggered sequentially to reduce the single-request payload size. This reduces the chance of a single point of failure in the API gateway.