Hi,
I am looking for best practices for implementing an automatic retry mechanism for a Script Action.
Current design:
Flow #1
- Creates a sysevent record.
- parm1 contains the target RITM sys_id.
- parm2 contains the retry count.
Script Action
- Triggered by the event and performs the main processing.
Flow #2
- Runs on a schedule.
- Searches for failed events.
- Automatically creates a new event to retry the processing.
The goal is to implement automatic retries, not manual reprocessing of events.
Issue:
I found that even when an unhandled JavaScript exception occurs in the Script Action, the sysevent state still becomes "processed" instead of "error".
Example:
(function() {
var x = null;
x.test();
})();
The Script Action terminates unexpectedly, but the event record is still marked as processed.
Requirements:
Retryable errors:
- Unexpected system errors
- Business errors that may be resolved later (for example, card stock shortage)
Non-retryable errors:
- Missing parameters
- Missing related records
- Invalid data
- Any condition that will not succeed even after retry
Currently I am considering the following options:
Option 1:
Store both retry count and error type in parm2.
Example:
5|STOCK_SHORTAGE
3|UNEXPECTED_ERROR
Option 2:
Add custom fields such as u_retry_count and u_error_type to the sysevent table.
Option 3:
Store retry status in a separate table or business record.
Questions:
1. What is the recommended approach for implementing automatic retry for Script Action processing?
2. Is it considered safe and supportable to add custom fields to the sysevent table?
3. How do you typically distinguish retryable and non-retryable errors in event-driven designs?
Any advice or examples would be appreciated.
Thanks.
