Redelivery on Error
If a processing step fails, this may be due to several reasons, some of them out of control of the user.
- The rendering process may have crashed.
- The cluster reorganizes processing nodes.
- The MAM system may be temporarily unavailable.
Some of these errors can be recovered by trying again after a delay. E.g., a MAM system may get available again after a short maintenance window.
Users can configure processing steps to automatically retry rendering if an error occurs.
The following processes support redelivery configurations in the config.ion:
- renderpdf
- renderpptx
- upload
- callback
- error
The following processes do NOT support redelivery configurations:
- transform
- If a transformation fails, we do not expect that the failure can be healed by just waiting a bit. Typically, the transformation configuration is wrong and needs to be fixed.
- mediaproxy
- If an attempt to read a media file fails, there will be no retry from within the proxy. The responsibility for retrying to fetch media files on the renderpdf, comet_pdf, or renderpptx process.
Redelivery Example Configurations
RenderPdf
// try up to 2 redeliveries if the exit code is any of 137 or 139 and wait for 180 seconds between the attempts
// otherwise try up to 1 redelivery wait for 60 seconds between the attempts
{
redeliverOnError: [
{
maxRedeliveries: 2,
redeliverIntervalMillis: 180000,
codePattern: "137|139",
},
{
maxRedeliveries: 1,
redeliverIntervalMillis: 60000,
},
],
}
Upload
// try one redelivery after 60 seconds if an upload request was not successful (any code other than 2xx)
{
redeliverOnError: [
{
maxRedeliveries: 1,
redeliverIntervalMillis: 60000,
},
],
}
Redelivery Configuration Properties
redeliverOnError
This configuration is applied if an error in comet_pdf or a webhook worker occurs.
- Data Type: Array of Redelivery objects
- Default: empty array
Using more than one Redelivery object can be useful if different exitCodes should lead to different kinds of redeliveries: If e.g., a comet_pdf error occurs, the exitCode is matched against the codePattern of the Redelivery objects in their order. The first matching Redelivery rule will be applied. Likewise, the HTTP status code of a failing webhook can be matched against the statusCodePattern of the first matching Redelivery object.
redeliverOnError.codePattern
Optional regular expression to match the exitCode of the process.
The pattern is defined as a regexp to support numerical as well as string codes.
For comet_pdf exit codes are integer values as listed in https://docs.priint-comet.com/InDesign/Plugins/comet_pdf.html#Exit_values. Additionally, you may receive general error 127 meaning that the start comet_pdf already failed.
For webhook workers exit codes are HTTP status codes different from 2xx.
- Data Type: Regular Expression String
- Default:
.*(match all)
redeliverOnError.maxAgeMillis
Optional maximum age of a redelivery job.
A redelivery that fails after this interval will automatically be regarded as a terminal error. Thus stopping the redelivery cascade even if maxRedeliveries is not reached. The job will then be dropped, and the error webhook will be executed (if configured).
This property is useful if you set maxRedeliveries > 1.
- Data Type: int
- Default: 0 (no age restriction)
redeliverOnError.maxRedeliveries
An optional number of redelivery attempts until dropping the job and executing the error webhook (if configured).
- Data Type: int
- Default: 0 (no redeliveries)
In most cases 1 is the best value: maxRedeliveries=1 means that rendering will be regarded as failed after two failed attempts. Waiting a longer time rarely solves the problem then. Do not set this to more than 2.
redeliverOnError.redeliverIntervalMillis
Optional number of milliseconds to postpone the redelivery of the job.
This is a minimum interval. The job will be rescheduled after the given interval. The real start time of the rescheduled job depends on the load of the rendering queue.
- Data Type: int
- Default: 0 (immediately scheduled for redelivery)
Do not set this property to 0. Errors may happen due to short living causes (e.g., a temporarily slow MAM system). Give the redelivery a chance to succeed by postponing it for some minutes, at least for 30 seconds.
Redelivery on Error Webhooks
The redelivery configuration for Error Webhooks is the same as or other webhooks. So, if the destination service for an error notification is not responsive for a short time, the job can be rescheduled for redelivery.
If the final error notification fails, then the process terminates and the job is registered as failed. The only way to find out about the error is to get the ticket status via a call to the GET /tenants/:tenant/projects/:project/tickets/:myTicketId endpoint. But even this information is short-lived (about 15 min).