1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/activejob/CHANGELOG.md

44 lines
1.4 KiB
Markdown
Raw Normal View History

* Added possibility to check on `:priority` in test helper methods
`assert_enqueued_with` and `assert_performed_with`
*Wojciech Wnętrzak*
* OpenSSL constants are now used for Digest computations.
*Dirkjan Bussink*
* Add a Serializer for the Range class
This should allow things like `MyJob.perform_later(range: 1..100)`
Communicate enqueue failures to callers of perform_later There is presently no clean way of telling a caller of `perform_later` the reason why a job failed to enqueue. When the job is enqueued successfully, the job object itself is returned, but when the job can not be enqueued, only `false` is returned. This does not allow callers to distinguish between classes of failures. One important class of failures is when the job backend experiences a network partition when communicating with its underlying datastore. It is entirely possible for that network partition to recover and as such, code attempting to enqueue a job may wish to take action to reenqueue that job after a brief delay. This is distinguished from the class of failures where due a business rule defined in a callback in the application, a job fails to enqueue and should not be retried. This PR changes the following: - Allows a block to be passed to the `perform_later` method. After the `enqueue` method is executed, but before the result is returned, the job will be yielded to the block. This allows the code invoking the `perform_later` method to inspect the job object, even in failure scenarios. - Adds an exception `EnqueueError` which job adapters can raise if they detect a problem specific to their underlying implementation or infrastructure during the enqueue process. - Adds two properties to the job base class: `successfully_enqueued` and `enqueue_error`. `enqueue_error` will be populated by the `enqueue` method if it rescues an `EnqueueError` raised by the job backend. `successfully_enqueued` will be true if the job is not rejected by callbacks and does not cause the job backend to raise an `EnqueueError` and will be `false` otherwise. This will allow developers to do something like the following: MyJob.perform_later do |job| unless job.successfully_enqueued? if job.enqueue_error&.message == "Redis was unavailable" # invoke some code that will retry the job after a delay end end end
2021-01-19 09:57:46 -05:00
* Communicate enqueue failures to callers of `perform_later`.
`perform_later` can now optionally take a block which will execute after
the adapter attempts to enqueue the job. The block will receive the job
instance as an argument even if the enqueue was not successful.
Additionally, `ActiveJob` adapters now have the ability to raise an
Communicate enqueue failures to callers of perform_later There is presently no clean way of telling a caller of `perform_later` the reason why a job failed to enqueue. When the job is enqueued successfully, the job object itself is returned, but when the job can not be enqueued, only `false` is returned. This does not allow callers to distinguish between classes of failures. One important class of failures is when the job backend experiences a network partition when communicating with its underlying datastore. It is entirely possible for that network partition to recover and as such, code attempting to enqueue a job may wish to take action to reenqueue that job after a brief delay. This is distinguished from the class of failures where due a business rule defined in a callback in the application, a job fails to enqueue and should not be retried. This PR changes the following: - Allows a block to be passed to the `perform_later` method. After the `enqueue` method is executed, but before the result is returned, the job will be yielded to the block. This allows the code invoking the `perform_later` method to inspect the job object, even in failure scenarios. - Adds an exception `EnqueueError` which job adapters can raise if they detect a problem specific to their underlying implementation or infrastructure during the enqueue process. - Adds two properties to the job base class: `successfully_enqueued` and `enqueue_error`. `enqueue_error` will be populated by the `enqueue` method if it rescues an `EnqueueError` raised by the job backend. `successfully_enqueued` will be true if the job is not rejected by callbacks and does not cause the job backend to raise an `EnqueueError` and will be `false` otherwise. This will allow developers to do something like the following: MyJob.perform_later do |job| unless job.successfully_enqueued? if job.enqueue_error&.message == "Redis was unavailable" # invoke some code that will retry the job after a delay end end end
2021-01-19 09:57:46 -05:00
`ActiveJob::EnqueueError` which will be caught and stored in the job
instance so code attempting to enqueue jobs can inspect any raised
`EnqueueError` using the block.
MyJob.perform_later do |job|
unless job.successfully_enqueued?
if job.enqueue_error&.message == "Redis was unavailable"
# invoke some code that will retry the job after a delay
end
end
end
*Daniel Morton*
* Don't log rescuable exceptions defined with `rescue_from`.
2020-11-02 16:12:47 -05:00
*Hu Hailin*
* Allow `rescue_from` to rescue all exceptions.
2020-11-02 16:12:47 -05:00
*Adrianna Chang*, *Étienne Barrié*
2020-12-02 18:37:26 -05:00
Please check [6-1-stable](https://github.com/rails/rails/blob/6-1-stable/activejob/CHANGELOG.md) for previous changes.