Retrying Event Handlers
On the Event Status and Event Handler Status forms, you can retry a failed event handler, if it is retryable. Whether a handler can be retried is determined by the cause of the failure and whether the event handler is marked as transactional, as shown here:
Cause of Failure |
Event transactional |
Handler transactional |
Retryable | Retry point |
Event Variables |
---|---|---|---|---|---|
Illegal operation | N/A | N/A | No | N/A | N/A |
Any legal operation | Yes | N/A | No | N/A | N/A |
Any legal operation | No | Yes | Yes | InitialAction | Re-initialized |
Unconditional Fail Event action | No | No | Yes | InitialAction | Re-initialized |
Conditional Fail Event action | No | No | Yes | CurrentAction | Maintained |
Unexpected error | No | No | Yes | CurrentAction | Maintained |
When retrying a single handler, whether the handler runs synchronously or asynchronously depends on the parameter passed to the API, not the handler’s definition. When retrying an event, the handlers are run as shown in this table:
Failed Synch Handler | Failed Asynch Handler | |
---|---|---|
Restarted synchronously | Synchronous | Asynchronous |
Restarted asynchronously | Asynchronous | Asynchronous |
An event can have a synchronous handler that is not retryable, but it still retries any asynchronous handlers that can be retried. In this case, any synchronous handlers that will come after the failed handler will not be run.
The Event or EventHandler Result must be cleared when retrying the handler. However, the previous handler result is saved in a handler variable called PreviousResult, and the event results are saved in an event parameter also called PreviousResult.