We have been experiencing an issue regarding service type events in one of our Service Desk instances. The events in call_reqs are not firing when they are reached. As a result, the events remain in "Pending" state forever (unless the request is Canceled or Closed, when the event is canceled too).
This is weird, since it was all working since two years ago, and suddenly we got this problem. I can reproduce this in a replicated environment, and it looks like this issue is happening on all requests/incidents and service types.
Because we are using SDM 12.7 which is out of service, I was investigating this on my own. I have discovered that every time an event is supposed to be fired, this error is written on stdlog:
09/14 16:23:19.14 VCSPECONSRV122 animator_nxd 5468 ERROR animator_nxd.c 1839 10 in animator ANI:402325 (cr:652896) for atev:627039 in method animation_complete09/14 16:23:19.29 VCSPECONSRV122 animator_nxd 5468 SIGNIFICANT animator_nxd.c 2121 Deleted animator ANI:402325 (cr:652896) for atev:627039 due to earlier failures during firing
Now, some theories about what could be happening: "10" may be an error code (or else, an "dead mark") for that event/animator. In "ani" table, most rows have the "10" value in "a_delta" column. But even the rows with "0" value were eventually "killed" too, which is strange.
Maybe there is a flag or a black list containing all events that are "died" for some reason (probably the "earlier failures during firing). When an event is triggered, maybe this animaton_complete function is called, and then it checks if the event is on "black list" or not.
So this raise some questions:
1. What this animation_complete method really does?
2. Why are these events are being "marked" as "failed"? And where?
3. How can I "clean" these events so the animator can fire again?
Could anyone help us on this?
PS: we're using classic SLA option since the beginning.
The error that you are seeing in your logs can be caused by the edit_inactive option being installed in Options Manager. Unless you have a need to modify closed tickets, you could try uninstalling that option to see if it makes a difference.
If you are still seeing the problem, you may want to review recent changes. Have there been any new events, ticket types, etc. added or changed? Have affected users recently changed their workflow for SLA events or anything related to that? Do you have a similar environment where the issue is not occurring that you could compare to find the differences? All of these may be useful in narrowing down the source of the issue, and it could also give you a better idea of how to solve it.
Some things we've already tried:
Thank you for your answer. We've found out the error was being caused by a macro that was recently added. We couldn't detect it at first, the log did not mention the macro anywhere. But we eventually discovered it. We are still checking what is wrong in the macro, but for now the problem was solved. Thanks!