Troubleshoot Ultra Tasks
The common issues you might encounter with Ultra Tasks include:
-
Ultra Tasks become disabled. Ultra Task configuration includes a Maximum Failures setting: a cumulative count, across every Snaplex node running an instance of the task, of failures to start and failures that occur after the pipeline has started running. When the count reaches the threshold, the Snaplex disables the Ultra Task. During development or troubleshooting, you might want to disable this feature or increase the number. For the complete list of cases when a Snaplex automatically disables an Ultra Task, see Ultra Tasks in production.
-
A pipeline does not start. A pipeline processes a document multiple times. If the FeedMaster does not receive an acknowledgment that a document was processed, it can be retried. By default, the document may be retried up to five times. You can change this in Snaplex configuration as described below in Configuring Snaplex Retries.
-
Unhandled errors. To troubleshoot errors and failures in a pipeline invoked by an Ultra Task, it is a good practice to implement error and exception handling as described below. When the pipeline handles errors and exceptions, the Snaplex will not automatically disable the Ultra Task.
Configure Snaplex retries
You can change the maximum number of allowed retries for document processing failures in Snaplex Node Properties. To do so, open the Snaplex Create or Snaplex Update dialog and follow these steps:
- Select the Node Properties tab.
-
In the Global Properties field, add the Key
ultra.max_redelivery_count. -
For Value, indicate the number of times the Snaplex should try reprocessing documents.
Error and exception handling
Use error handling to avoid failures, disabling of the Ultra Task or a service disruption. You can add Error handling to pipelines invoked by Ultra Tasks by following these guidelines:
Add an error view to all crucial endpoint application Snaps in the pipeline to return a response with custom error messages (code and HTTP status code). Doing so notifies you of errors in the document processing. For example, the Mapper Snap used in the pipeline below allows customizing information for error content when the REST Post Snap fails.

[{
“response codes”: [{
“400”: {
“error code”: “4000”,
“error message”: “Malformed request body or missing a required parameter”
}
}, {
“401”: {
“error code”: “4010”,
“error message”: “No valid session key or credentials provided”
}
}]
}]ultra.max_redelivery_count to indicate the number of times you want a
failed Ultra Task to run.Ultra Tasks require a document
type output in the Error Pipeline. The following pipeline provides an example of an error pipeline
set up for error handling in asynchronous Ultra Tasks:
The following describes the setup for each Mapper Snap.
In the first branch,
the first Mapper (Map - Build Pipeline…) specifies the runtime records to pull the errors
from.
The subsequent Mapper Snap (Map Error Records) lists which errors to
pass.
The error messages are copied and sent to a specified email address and log in one
branch. In the original branch, a Mapper Snap (Map REST - Reply) defines the REST
response.
We add a JSON Formatter (Status Output) after the Mapper with the HTTP status code
format.
The final Mapper gives the response output as a document.
You can Download the pipeline to reuse for your Ultra Pipeline.