Campaign is sitting at 1.3x pacing on the 2024-10-15 release, US-East tenant. The custom JavaScript block in the outbound flow keeps bailing out the moment the predictive dialer routes a call. Console spits out ReferenceError: Cannot read properties of undefined (reading 'contactAttributes') right before the agent desktop loads the script. The flow hits /v2/outbound/campaigns/{id}/contacts but the payload comes back null when the multiplier spikes. Abandonment rate jumps to 4.2% because the script hangs and the dialer drops the call. Tried caching the attributes in a flow variable first, but the timeout still hits. The admin UI for the script editor just spins when trying to save the updated block. It’s completely unresponsive. Pacing has to stay above 1.2x to hit volume targets, so dropping to progressive won’t work. Logs show execution time ballooning to 800ms before the crash. Compliance window is locked to 9am-5pm ET. Script block throws a 429 on the lookup endpoint if the queue depth gets too high. Doing jack all to fix it. Mic stays hot while the flow retries.
{"error": "SCRIPT_TIMEOUT", "flowId": "f8a9c21d-4e5b-41a2-9c3f-88d12e44a091", "timestamp": "2024-11-14T14:22:01.000Z"}
The ReferenceError usually means the script is trying to access contactAttributes before the REST Proxy action has actually resolved. When pacing hits 1.3x, the latency on the /v2/outbound/campaigns/{id}/contacts call can push the response past the script’s execution window, leaving the variable undefined.
You need to force a synchronous wait or add a null check before accessing the object. In the REST Proxy action doesn’t auto-pause the flow unless you configure the “Wait for response” toggle correctly. If that’s off, the next block runs immediately with an empty payload.
Here is how to structure the error handling in the subsequent JavaScript block to prevent the crash:
// Check if the previous action result exists and has data
if (context.previousActionResult &&
context.previousActionResult.responseBody &&
context.previousActionResult.responseBody.contactAttributes) {
let attrs = context.previousActionResult.responseBody.contactAttributes;
// Safe to use attrs here
context.setVariable("agentScriptData", JSON.stringify(attrs));
} else {
// Fallback for high latency or null response
context.setVariable("agentScriptData", "{}");
context.log("Warning: Contact attributes null. Using fallback.");
}
Also check your REST Proxy timeout settings. The default might be too tight for peak pacing. Bump it up to 5000ms. If the API doesn’t return in that window, the script should fail gracefully rather than throwing a hard error. This keeps the call alive even if the data is stale.
One more thing. Make sure you aren’t using contactAttributes as a direct variable name in the script block without prefixing it with the action result path. variables are scoped to the action. If you reference contactAttributes directly in JS, it looks for a global variable which doesn’t exist. Always pull from context.previousActionResult or context.variables depending on where you stored it.
The 404s you mentioned in previous threads might be related to this timing issue too. If the participant isn’t fully initialized when you try to patch attributes, the API rejects it. Same principle. Wait for the state to stabilize before writing.