1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/activejob/test/cases/queuing_test.rb

58 lines
1.6 KiB
Ruby
Raw Normal View History

2017-07-09 13:49:52 -04:00
# frozen_string_literal: true
require "helper"
require "jobs/hello_job"
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
require "jobs/enqueue_error_job"
require "active_support/core_ext/numeric/time"
2014-05-18 06:32:22 -04:00
2014-05-18 05:44:28 -04:00
class QueuingTest < ActiveSupport::TestCase
2014-05-18 06:32:22 -04:00
setup do
2014-08-17 09:23:24 -04:00
JobBuffer.clear
2014-05-18 06:32:22 -04:00
end
test "run queued job" do
2014-08-25 10:34:50 -04:00
HelloJob.perform_later
2014-08-17 09:23:24 -04:00
assert_equal "David says hello", JobBuffer.last_value
2014-05-18 06:32:22 -04:00
end
test "run queued job with arguments" do
2014-08-25 10:34:50 -04:00
HelloJob.perform_later "Jamie"
2014-08-17 09:23:24 -04:00
assert_equal "Jamie says hello", JobBuffer.last_value
2014-05-18 05:44:28 -04:00
end
test "run queued job later" do
result = HelloJob.set(wait_until: 1.second.ago).perform_later "Jamie"
assert result
rescue NotImplementedError
skip
end
test "job returned by enqueue has the arguments available" do
2014-08-25 10:34:50 -04:00
job = HelloJob.perform_later "Jamie"
assert_equal [ "Jamie" ], job.arguments
end
test "job returned by perform_at has the timestamp available" do
job = HelloJob.set(wait_until: Time.utc(2014, 1, 1)).perform_later
assert_equal Time.utc(2014, 1, 1).to_f, job.scheduled_at
rescue NotImplementedError
skip
end
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
test "job is yielded to block after enqueue with successfully_enqueued property set" do
HelloJob.perform_later "John" do |job|
assert_equal "John says hello", JobBuffer.last_value
assert_equal [ "John" ], job.arguments
assert_equal true, job.successfully_enqueued?
assert_nil job.enqueue_error
end
end
test "when enqueuing raises an EnqueueError job is yielded to block with error set on job" do
EnqueueErrorJob.perform_later do |job|
assert_equal false, job.successfully_enqueued?
assert_equal ActiveJob::EnqueueError, job.enqueue_error.class
end
end
2014-05-18 05:44:28 -04:00
end