ActiveJob is used to enqueue and run the tasks in the background. But a job can fail because of many reasons. Say a network issue while communicating to the underlying datastore or non-availability of the datastore, etc.
ActiveJob has added the ability to communicate the failures related to enqueuing the job to the caller. This will allow developers to have a better grasp of the flows related to the job enqueue.
perform_later, there was no clean way for the caller to understand
the reason behind job enqueue failures.
If the enqueuing succeeded, the method would return the job object.
But if the job could not be enqueued, it would just return
one would have to search the logs or implement something peculiar to find out what’s wrong.
After the change
The commit will allow
perform_later to optionally accept a block. Irrespective of the enqueuing status, the block will receive a job instance as an argument.
This is achieved by
given block after the
enqueue method is executed but before the result is returned.
This will be helpful not only in failure scenarios but will also help in those rare scenarios where one wants to do something right after a successful enqueue.
Heres an example of the
perform_later method with a block,
We can see the safe navigation at
That’s because the
enqueue_error is assigned to the job instance only when the underlying adapter raises an
It’s a new exception class added which can be used by the adapters (eg: Sidekiq, DelayedJob) for enqueue-related errors.
To summarize, the job instance will have two new properties
Out of which
enqueue_error will be populated only when an
EnqueueError is rescued.