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

59 lines
1.9 KiB
Markdown
Raw Normal View History

* Allow a job to retry indefinitely
The `attempts` parameter of the `retry_on` method now accepts the
symbol reference `:unlimited` in addition to a specific number of retry
attempts to allow a developer to specify that a job should retry
forever until it succeeds.
class MyJob < ActiveJob::Base
retry_on(AlwaysRetryException, attempts: :unlimited)
# the actual job code
end
*Daniel Morton*
* Added possibility to check on `:priority` in test helper methods
2021-07-20 21:08:08 -04:00
`assert_enqueued_with` and `assert_performed_with`.
*Wojciech Wnętrzak*
* OpenSSL constants are now used for Digest computations.
*Dirkjan Bussink*
2021-07-20 21:08:08 -04:00
* Add a Serializer for the Range class.
2021-07-20 21:08:08 -04:00
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.