From the Dretails section you can click on the Error # and go directly to the error.
In the sections below we'll describe how to read, and troubleshoot various workflow errors.
Along the top of the console is the Error Id and information about the original run (including a link to the tree).
Below that are tabs for the Details (default) and the Resolution (covered later). And on the right side is a button to open the Builder. If you chose to open the builder and the error is based on a node, that node will be highlighted and placed in the middle of the screen.
The section in blue is for resolving errors and recording actions taken. It is covered in a section below.
The Details section contains any specific information about the error from the the Task engine. Normally, this is a stack trace.
Connector errors are similar, but include a little more information around the two nodes that are the start and end of the connectors.
In the next sections are some common task errors and potential fixes. The desire is to give you some ideas for troubleshooting. So much in Kinetic workflows is personalized to the customer that it is often impossible to give exact solutions.
You can see this error in the connector error description above. It indicates that a reference to a node name is missing, incorrect, or hasn't been executed yet.
For example, in the connector error, ApprovalValue has either not been returned yet, or is incorrectly identified.
This error indicates that within either the handler code, or code in a node parameter, a method was called, but no value was provided.
For example in your handler you have the following code to convert a string variable to an integer x.to_i. If x is nil (null for ruby), you will get the nil:NilClass.
The stack trace will often show a line number in the init.rb file that relates to this error.
This error happens when a trigger tries to complete a deferred node that has already been completed.
Because you cannot retry the trigger in this case, the Resolve Error section only allows you to enter notes (required).
The task engine provides a built-in mechanism for retrying errors in the Resolve Errors section of the error task. In any case where you are able to resolve an error, there is an Additional Actions drop-down with three choices, and a Notes field to record any extra notes (normally for either auditing or future troubleshooting purposes).
It may be necessary, after fixing data that caused an error, to also update where that data appears in inputs or results in the workflow run. There are a couple of places on the Run where you can edit the data yourself and then use the Retry Task option to resolve an error.
Inputs are available at the top of every Run. If you know that an input values is incorrect or invalid (for example an answer is blank or not what is expected), you can update the inputs and either retry or run the tree again. Be careful re-running the tree, you could duplicate messages or other actions created by the tree.
Make use of the audit message to explain any edits of the input data.
Each node that generates Results has the ability to edit those results. Example of a Task Result: Task does not allow you to makeup a new Result value, so you are limited to the results defined in the task.
Changing the results here will only have an effect on any Task that runs after the change. Completed tasks are not updated.
The platform allows retries of errors that will consistently have the desired behavior after being retried. For example, we know that if a handler raises an exception that the tree has not done any downstream processing and the node can safely be retried. In other cases, such as a malformed tree, it is impossible to know the expected vs actual outcome so the platform can't effectively allow retries.
Errors that can be retried:
Errors that can not be retried: