Retrying application event handlers

On the Event Status form and the Event Handler Status form, 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 in this table:

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 Sync Handler	Failed Async 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 do not 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.