Hi All,
I've got an interesting situation where a data action to fetch an object in service now works fine in the action ui when I test it (and, alternately as a lambda that I run both from genesys and another application), but when I use the action in a flow it times out every time, immediately. I've re-published it on several occasions with slight tweaks, and have used the corresponding lambda api get with the same results... test fine but times out in the flow.
How can this be? Is there a way I can generate some additional logging from Genesys on this to help with troubleshooting?
Are you sure it is taking the timeout path, not the error path?
Yeah. When I troubleshoot stuff i put audio blocks in the path to let me know what's going on:
And the interesting thing is that even if i override the timeout value in the action itself, it still times out immediately:
I put this action in my dev org and it's doing the same exact thing. It's almost like the api itself is sending some kind of time out value that the function is responding to. But I'm not sure how that could be.
What governs the time out timer... Genesys does that independently of the endpoint correct?
I put in a support request with Genesys on this. Any input here? What decides that an action has timed out?
The timeout is enforced by the edge. Previous reports of Data Actions instantly failing have typically been due to having architect configured to use the wrong variable types to bind to the data action input or output. I would expect those types of problems to result in the Failure path being taken, so I am glad that you have a support case open.
--Jason
1 Like
Can support get a log from the edge to determine what it's seeing? I feel like that endpoint is returning a 200 but also indicating that it's timing out?
Yes, support can collect edge logs to see exactly what is going on. I can't, which is why I am glad you opened up a support case 
--Jason
1 Like
After some struggles getting my test environment working again, I was finally able to test this out a bit in architect. I was not able to find a way to reproduce your issue by messing with variable bindings. I am really curious to hear the results of your support case.
--Jason
So the request that I was making was for an announcement endpoint in service now. One of the attributes that I am returning was "public", which in service now is a boolean governing who can see the object. Evidently is a reserved word for javascript.
Of course, the trouble here is that it was working when tested from the action, and not then timing out when called from architect, not failing outright, so this is pretty confusing.
My preference would be that it fails when tested and returns an error code indicating the nature of the problem.
Hi dmthames,
Data actions are not JavaScript based, so a JavaScript reserved word wouldn't cause any problems during testing or execution. And since you can use data actions in a number of ways my first instinct is not to impose JavaScript rules on top of them.
I will ping the architect team to see if they want to chime in on this.
--Jason
Hi Dean,
Thank you for letting us know about these issues, and I'm sorry about the inconvenience and time you had to spend. I would like to get to the bottom of both (the failure when using a reserved word, and the timeout vs. error). Unfortunately, the edge logs associated with the conversationIds in case 0002887644 are no longer available. I hate to ask this of you, but if you could reproduce the problem one more time and post the conversationId here that would be very helpful. With that I can download the corresponding Edge logs and see exactly what is going on. Thanks in advance!
-Tom
i'd be happy to. might can get to it this afternoon, but certainly by end of week. would just the conversation id suffice, or would you need more info to track it down?
Hi Dean. The conversation ID is all that I would need. Thanks!
-Tom
One more thing: there was a fix for the timeout (vs. error) path that went out in the mid March timeframe. It will take a flow republish to pick up that fix. So If you could republish your flow before you run the test that would be very helpful. Hopefully it will take the failure path, but if not, I should be able to track it down. Thanks again.
-Tom
Hi @anon88270151 ... sorry for the delay. So the action test from the gui works with the attribute named public, but the actual action fails when called in the flow from architect. This is different from the prior event where the call to the timeout route instead of the fail route.
The details are:
test event: 4/13 @ approx 1:41 pm EST
flow: 0855236f-8f00-45d1-9901-df0802e44040
task: f280a64d-3b62-4142-9717-d5386fdaa595/48132b57-9d79-42dc-b4e2-958acc6913ad
action: custom_-_305bafc5-0270-40a8-8fa2-8305e3c29173
Hi Dean. No worries, and thanks for the update! That's good to hear about it taking the failure path instead of the timeout path (it's more verification that the fix we put in for that a few weeks ago is working).
If you happen to have a conversation ID handy that would be helpful in narrowing down the right log (let me know if you need assistance on how to get that). Thanks.
-Tom
Yep, it's 7a0afe7e-d4e6-416f-ac54-bdb2b62604e4
Hi Dean,
I've been looking at this as Tom is currently out of the office. I investigated your example and confirmed the action is indeed failing due to using a ECMAScript reserved word in the response, "public" as you noted, so takes the failure path of the action immediately as a result. Please keep this in mind and work around it by changing that properties' value to continue testing in the mean time, once Tom returns we will discuss this further and see what can be done.
