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.

### Before

While calling 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 false and 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 yielding 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 job.enqueue_error&.message. That’s because the enqueue_error is assigned to the job instance only when the underlying adapter raises an EnqueueError. 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 successfully_enqueued and enqueue_error. Out of which enqueue_error will be populated only when an EnqueueError is rescued.