Studio Data Action 504 on SNIPPET payload transformation with REST Proxy v4.2.1.8

The outbound routing flow hits a custom Data Action built in Studio, which calls an internal REST endpoint via a SNIPPET action. Everything worked fine until Tuesday. Now the SNIPPET transformation step hangs for exactly 12 seconds before returning a 504 Gateway Timeout. The REST Proxy is configured to point at our London BYOC cluster, running on version 4.2.1.8.

Reasoning through the failure path first. Step one: the flow pulls the contact record using a standard Data Action. Step two: a SNIPPET action parses the JSON response and maps the customFields array into a new variable. The SNIPPET code looks like this: const mapped = payload.customFields.map(f => ({ key: f.name, val: f.value })); return { data: mapped };. Studio marks the action as successful, but the actual HTTP request never leaves the edge.

Checked the network traces. The TLS handshake completes without issue. The problem sits right at the payload serialization stage. When the SNIPPET object exceeds roughly 4KB, the REST Proxy drops the connection. Shrinking the payload to 2KB fixes it immediately. Doesn’t make much sense since the docs state a 64KB limit for SNIPPET context variables.

The flow is running on the CXone US-East environment, but the BYOC edge is definitely routing through eu-west-2. Cross-region latency shouldn’t break a local variable assignment. The console just spins. Doing jack all while the queue backs up. Mic stays hot on the test line.

Tried bypassing the SNIPPET and passing the raw JSON directly to the REST Proxy call. Same timeout. The x-request-id header matches across all logs, but the server-side trace shows a ERR_HTTP_HEADERS_TIMEOUT right after the Content-Length header gets written. Maybe the new Studio runtime patch changed how the SNIPPET engine handles async promises? The build was deployed at 09:15 GMT. All the other flows using the same SNIPPET action are throwing TypeError: Cannot read properties of undefined (reading 'map') now.

{
“error”: “timeout”,
“code”: 504,
“details”: “SNIPPET execution exceeded 12000ms”,
“trace”: “flow_id: 8842-a1b, action: transform_contact_data”
}

The payload structure hasn’t changed in months. The REST Proxy config is identical. Just the runtime version bumped to 2.3.1.0. The edge logs cut off right after the…

Don’t trust the SNIPPET action for heavy lifting in this version. It’s a known bottleneck with 4.2.1.8 when the payload exceeds 15kb or contains nested objects. The 12-second hang is the default timeout for the internal transformation engine before it bails.

Switch to a REST Proxy action directly. Skip the SNIPPET wrapper entirely.

{
 "name": "GetContactData",
 "type": "RESTProxy",
 "configuration": {
 "url": "https://your-london-cluster.niceincontact.com/api/v2/contacts/{{contactId}}",
 "method": "GET",
 "headers": {
 "Authorization": "Bearer {{authToken}}",
 "Content-Type": "application/json"
 },
 "timeout": 5000,
 "ignoreErrors": false
 }
}

Set the timeout explicitly to 5000ms in the action config. If the London cluster is lagging, you’ll see a clean error instead of a silent 504. The SNIPPET layer adds an extra hop that chokes on JSON deserialization in this patch.

Check the REST Proxy logs in the BYOC dashboard. Look for transform_timeout errors. You’ll likely see the payload size spike right before the drop.

Cause: The 12-second hang isn’t the proxy. It’s the token refresh. Your London BYOC cluster is likely hitting a stale auth endpoint or a misconfigured redirect URI for the OAuth token request. The docs state: “Token requests must include the client_id and client_secret in the Basic Auth header, not the body.” If your SNIPPET is trying to parse a body-based response or waiting for a redirect that never comes, it times out exactly when the internal HTTP client gives up.

Solution: Switch to a direct REST Proxy with explicit OAuth headers. Don’t let Studio guess the auth method. Use this config:

{
 "name": "GetContactData",
 "type": "RESTProxy",
 "configuration": {
 "url": "https://your-london-c.byoc.genesys.cloud/api/v2/contacts/{id}",
 "method": "GET",
 "headers": {
 "Authorization": "Bearer {{token}}"
 }
 }
}

Ensure the {{token}} variable is refreshed via a separate Data Action using client_credentials grant. Check the BYOC audit logs. They’ll show if the token request is failing silently.