Right now, unless you as a user of the library add special handling, if TargetsMany#perform_on_target encounters an error the exception will propagate up to Sidekiq which will dutifully re-try the job from the beginning, potentially causing undesired behavior if jobs are not idempotent. We need to handle this case more gracefully.
Possible solutions (neither exclusive nor exhaustive):
Run perform_on_target in a rescue block and add a handle_exception method (to allow the below and/or allow user-specified behavior)
Track completed targets on on the ActionModel instance and skip over them when iterating over targets (to make the job idempotent)
Track errored targets on the ActionModel instance and provide some sort of retry mechanism, maybe by duplicating the action with just the errored targets as the new target list
A larger but probably very useful refactor: (optionally) queue each perform_on_target as a separate Sidekiq task and use batches (if available) to tie them together and track progress. With this we get automatic parallelization, completion tracking, and one bad target doesn't cause the whole batch to spin.
Right now, unless you as a user of the library add special handling, if
TargetsMany#perform_on_targetencounters an error the exception will propagate up to Sidekiq which will dutifully re-try the job from the beginning, potentially causing undesired behavior if jobs are not idempotent. We need to handle this case more gracefully.Possible solutions (neither exclusive nor exhaustive):
perform_on_targetin a rescue block and add ahandle_exceptionmethod (to allow the below and/or allow user-specified behavior)A larger but probably very useful refactor: (optionally) queue each
perform_on_targetas a separate Sidekiq task and use batches (if available) to tie them together and track progress. With this we get automatic parallelization, completion tracking, and one bad target doesn't cause the whole batch to spin.