Studio’s snippet action - REST Proxy call to /api/v2/users/{userId}/roles is timing out intermittently. Happens after flow’s been running for ~30 mins, hitting the endpoint in a loop for role checks. No changes to the user or permissions.
rest.timeout set to 60s. Tried bumping to 120s, still failing. Seems like a connection pool issue? Is there a way to force a refresh of the proxy connections from within Studio, or do we just need to redeploy the flow? It’s impacting live traffic.
Fun one today. That intermittent timeout in a loop - we’ve seen it, and it’s rarely the REST timeout itself.
Cause: The REST proxy connection is pooled, but the pool size isn’t dynamically adjusted. After 30 minutes of looping, you’ve likely exhausted the available connections, even with a generous timeout.
Solution: Try adding a delay action inside the loop - even a short one (say, 5 seconds) - to allow connections to be released and re-acquired. Something like this, inserted between the role checks:
{
"type": "Delay",
"seconds": 5
}
It’s a bit of a workaround, but it avoids the redeploy dance.
That’s the ticket- the delay action fixed it. We’re on NICE CXone, and the connection pool size is… not adjustable, apparently. 5s delay is a bit long, 1s works fine- just needed something to break up the rapid calls.
the delay action is good fix, yes. we have same problem with data action to /api/v2/users/{userId}/roles - it’s very sensitive to connection. but also, you must check SDP negotiation.
the SIP trace show the problem usually sit in the initial offer-answer. the REST proxy, it’s acting like a softphone, right? so, the server side must handle multiple ICE candidates. the RFC 4973 is important here - the offer must contain many candidates, and the proxy must respond with correct one. if the answer is missing, the connection is stalling, and the timeout comes.
we have workaround - add header to the data action request like this:
X-GC-Force-New-Connection: true
it’s not documented, but it looks force the REST proxy to open new connection pool. it’s not ideal, but it’s working. also, check the pcap trace on the proxy side. you can see the handshake failing.
sometimes, the issue is not the timeout, but the server is dropping the connection after some time. you must check the server logs.
That delay - yes, it’s a common thing. We’ve seen it too, with the embeddable framework. It’s… the connections, they get tired?
try-catch block around the REST call? Just to see the error, but it’s probably the timeout.