Currently, the `perform_enqueued_jobs` helpers will also immediately
perform jobs that are scheduled via `set(wait:)` to run in the future.
This commit adds a new argument to `perform_enqueued_jobs` to make it
only run jobs scheduled at or before the passed in `Time`. This allows
testing the side effects of immediate job execution separate of jobs
delayed in the future.
`assert_enqueued_with` and `assert_performed_with` were not able to
properly test jobs with relative delay. `:at` option was asserted for
equality and test will always fail cause small fraction of time will
pass between job call and assertion.
This commit fixes that by droping microseconds from `:at` argument
assertions.
Rails 6 introduces retries per-exception, instead of a global count of
retries. Because ActiveJob 5.2 doesn't serialize the execution count
per-exception, when ActiveJob 6.0 picks up an "old" job it can't know
the exception count in the new format.
This can also be an issue if AJ 6.0 serializes a new job with
exception_executions which is later picked up by AJ 5.2, which would
clear exception_executions (since it has no knowledge of it).
Previously we handled this by resetting exception_executions, if it
wasn't defined on a job, which could result in the worst case retrying
the job 2x the times we should.
This commit changes how we handle loading a legacy job: instead of
resetting exception_executions, we instead will always use the global
executions count.
This way, jobs which only have one retry_on (and didn't have a behaviour
change in AJ 6) are backwards-and-forwards-compatible with counts
respected exactly.
Jobs with multiple retry_on will revert to the AJ5.2 behaviour if they
were ever run under AJ5.2.
Individual execution counters were introduced in #34352. However
`#determine_delay` which is used to calculate retry delay still uses the
global counter. This commit fixes it.
Motivation:
- Currently we have 2 seperate monkey patches in place for tracking
enqueded time for 2 seperate workers. It seems that activejob could be
a source of truth for how long an item has been enqued so that we can
easily use it for consistent monitoring across workers/apps to ensure
that jobs are running at an acceptable speed.
Changes:
- Add an enqueded at attribute and serilization tooling.
- Add a method to get how long a job has been enqueded for.
- Add a logging item to show how long a job was enqued prior to the
perform method firing.
Previously, by extending ActiveJob::TestCase, the test adapter provided
for tests was being used always, in all executions where supposedly
different adapters were being used. As a consequence, some bugs visible
only for some adapters might have gone undetected. This commit changes
that, skipping queue adapters for which we can't test scheduling jobs
with a delay.
Also, make tests and examples for individual execution counters
clearer, as it wasn't entierly clear what would happen in this case:
```
retry_on CustomException, OtherException, attempts: 3
```
The job would be retried at most 3 times in total, for both
CustomException and OtherException. To have the job retry 3 times at
most for each exception individually, the following retry_on
declarations are necessary:
```
retry_on CustomException, attempts: 3
retry_on OtherException, attempts: 3
```
Trusting any GlobaID object when deserializing jobs can allow
attackers to access information that should not be accessible to them.
Fix CVE-2018-16476.
* Keep executions for each specific declaration
Fixes#34337
ActiveJob used the global executions counter to control the number of
times a job should be retried. The problem with this approach was that
in case a job raised different exceptions during its executions they
weren't retried the number of times defined by their `attemps` number.
**Example:**
Having the following job:
```ruby
class BuggyJob < ActiveJob::Base
retry_on CustomException, attemps: 3
retry_on OtherException, attempts: 3
end
```
If the job raised `CustomException` in the first two executions and then
it raised `OtherException`, the job wasn't retried anymore because the
global executions counter was already indicating 3 attempts.
With this patch each `retry_on` declaration has its specific counter so
that the first two executions that raise `CustomException` don't affect
the retries count that future exceptions may have.
* Revert "clarifies documentation around the attempts arugment to retry_on"
This reverts commit 86aa8f8c5631f77ed9a208e5107003c01512133e.
- That feature is useful to enqueue or assert that jobs got enqueued
or performed based on dynamic conditions.
We will be able to leverage that feature to fix all ActionMailer
assertion helper issue when a Mailer define a custom delivery job
(see next commit).
Fixes#34366
Currently setting queue_name_prefix will not combine a prefix with the
default_queue_name; it will only affect queue names set with `queue_as`.
With this PR the prefix will affect the default_queue_name as well.
Closes#19831
Currently setting default_queue_name doesn't actually affect the
queue_name default (although default_queue_name does get used if you
pass a falsey `part_name` to `queue_as`). This PR would get
default_queue_name working as expected as well.
Because the queue_name default is now a lambda wrapping the
default_queue_name, rather than the default_queue_name itself, I had to
update one test to use the instance method `#queue_name` (which
`instance_exec`s the value) instead of the class method. I think this
change is OK, since only the instance method is documented.
There was a question about whether we want a `default_queue_name`
configuration. If we want to get rid of it, I would also be happy to
open a PR for that instead. It has been around for a while now, but it
also hasn't really worked for a while now.
r? @matthewd
since you had an opinion about this before
Since `@mutex.synchronize` is enforced in the `ensure_connection!` method,
there is no need to do so on the caller side.
c1b47f9c5d/lib/sneakers/publisher.rb (L22-L26)
Due to this, `ThreadError(deadlock; recursive locking)` has occurred.
`assert_enqueued_with` and `assert_performed_with` return a instantiated
instance of the matching job for further assertion (#21010).
Before this commit the `arguments` method on the returned instance
returns a serialized version of the arguments.
- When calling `assert_performed_with`/`assert_enqueued_with`, the
+args+ needs to match exactly what the job get passed.
Some jobs can have lot of arguments, or even a simple hash argument
has many key. This is not convenient to test as most tests doesn't
need to check if the arguments matches perfectly.
This PR make it possible to only check if a subset of arguments were
passed to the job.
Since #33751 was added `enqueue_retry.active_job` instrumentation to
the `retry_on` method, then #33897 moved the instrumentation to `retry_job`
method in order to ensure that this method publish `enqueue_retry.active_job`
notification too.
See related discussion https://github.com/rails/rails/pull/33751#discussion_r214140008
Since `enqueue_retry.active_job` moved to `retry_job`, there is no guarantee
that payload of `enqueue_retry.active_job` would have `:error`.
See test `LoggingTest#test_enqueue_retry_logging_on_retry_job` as
example of that case.
Related to https://github.com/rails/rails/pull/33897#discussion_r219707024
I think we can improve notification of `enqueue_retry.active_job`:
- If there is no `event.payload[:error]`, then publish like
"Retrying RescueJob in 3 seconds." only.
- If `event.payload[:wait]` is `nil`, then publish
"Retrying RescueJob in 0 seconds." instead of "Retrying RescueJob in nil seconds."
- If there is `event.payload[:error]`, then publish
"Retrying RescueJob in 3 seconds, due to a DefaultsError.".
- Change the type of the message from `error` to `info.`
Also, this commit removes part of messages - "The original exception was #{ex.cause.inspect}."
of `enqueue_retry.active_job`, `retry_stopped.active_job`, and `discard.active_job` since I
haven't found it useful. Please let me know whether you agree with that?
psqlrc files can affect the execution of commands in ways that can hold
up execution by blocking or otherwise cause unexpected side effects and
should best be ignored when using psql programmatically.
Currently when executing `bundle exec rake test:integration` under `activejob/`
derectory, it prints helpful info like:
```
(snip)
*** rake aj:integration:async ***
(snip)
*** rake aj:integration:delayed_job ***
(snip)
```
but there is no defined `:aj` scope in `activejob/Rakefile`,
so I think output should be like:
```
(snip)
*** rake test:integration:async ***
(snip)
*** rake test:integration:delayed_job ***
(snip)
```
By the way `rake test:integration` doesn't work if execute it without
prepending `bundle exec` to that command. It is probably what we should
fix too.
The priority wasn't being passed from ActiveJob to Backburner, despite
priority being supported. This also brings it inline with the docs,
which mark Backburner as supporting priorities in the "Backend Features"
table: https://api.rubyonrails.org/classes/ActiveJob/QueueAdapters.html
If the `:queue` option is specified, then only the job(s) enqueued to a specific
queue will not be performed.
Example:
```
def test_assert_no_performed_jobs_with_queue_option
assert_no_performed_jobs queue: :some_queue do
HelloJob.set(queue: :other_queue).perform_later("jeremy")
end
end
```
If the `:queue` option is specified, then only the job(s) enqueued to a specific
queue will be performed.
Example:
```
def test_assert_performed_jobs_with_queue_option
assert_performed_jobs 1, queue: :some_queue do
HelloJob.set(queue: :some_queue).perform_later("jeremy")
HelloJob.set(queue: :other_queue).perform_later("bogdan")
end
end
```
If the `:queue` option is specified, then only the job(s) enqueued to
a specific queue will be performed.
Example:
```
def test_perform_enqueued_jobs_with_queue
perform_enqueued_jobs queue: :some_queue do
MyJob.set(queue: :some_queue).perform_later(1, 2, 3) # will be performed
HelloJob.set(queue: :other_queue).perform_later(1, 2, 3) # will not be performed
end
assert_performed_jobs 1
end
```
Follow up #33265
[bogdanvlviv & Jeremy Daer]
Currently, the execution count increments after deserializes arguments.
Therefore, if an error occurs with deserialize, it retries indefinitely.
In order to prevent this, the count is moved before deserialize.
Fixes#33344.
It can be asserted that no jobs are enqueued to a specific queue:
```ruby
def test_no_logging
assert_no_enqueued_jobs queue: 'default' do
LoggingJob.set(queue: :some_queue).perform_later
end
end
```
Rename `in_block_job` to `enqueued_job` since this variable can refer not only
to jobs that were created in the block.
See #33258.
Return back accidentally removed test to activejob/test/cases/test_helper_test.rb
See #33258.
Fix name of tests.
Example of `assert_enqueued_with` with no block
```ruby
def test_assert_enqueued_with
MyJob.perform_later(1,2,3)
assert_enqueued_with(job: MyJob, args: [1,2,3], queue: 'low')
MyJob.set(wait_until: Date.tomorrow.noon).perform_later
assert_enqueued_with(job: MyJob, at: Date.tomorrow.noon)
end
```
Example of `assert_enqueued_email_with` with no block:
```ruby
def test_email
ContactMailer.welcome.deliver_later
assert_enqueued_email_with ContactMailer, :welcome
end
def test_email_with_arguments
ContactMailer.welcome("Hello", "Goodbye").deliver_later
assert_enqueued_email_with ContactMailer, :welcome, args: ["Hello", "Goodbye"]
end
```
Related to #33243
When a job was just deserialized `arguments` is `nil` and the serialized
arguments are in the `@serialized_arguments` variable. If we try to
serialize this job again the arguments are going to be `nil` instead of
what was serialized.
The test we had was not checking this case because it was deserializing
the job in the same object that had the arguments.
To fix this, when the `@serialized_arguments` are present we return it
instead of the result of the `arguments` serialized.
Reasons are that the Qu gem wasn't compatible since Rails 5.1,
gem development was stopped in 2014 and maintainers have
confirmed its demise. See issue #32273
Record what was the current timezone in effect when the job was
enqueued and then restore when the job is executed in same way
that the current locale is recorded and restored.
The serializer serializes an instance of `ActiveSupport::TimeWithZone`.
The serializer deserializes value to `ActiveSupport::TimeWithZone` if possible.
We can speed up things for the supported types by keeping the code in the
way it was.
We can also avoid to loop trough all serializers in the deserialization by
trying to access the class already in the Hash.
We could also speed up the custom serialization if we define the class
that is going to be serialized when registering the serializers, but
that will remove the possibility of defining a serialzer for a
superclass and have the subclass serialized using it.
Now custom serialziers can register itself in the serialized hash using
the "_aj_serialized" key that constains the serializer name.
This way we can avoid poluting the hash with many reserved keys.
Currently, sidekiq integration test + Ruby 2.5.0-rc1 show exception as follows.
```
#<Thread:0x000000000670bec0@/home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.0.5/lib/sidekiq/util.rb:23 run> terminated with exception (report_on_exception is true):
/home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/bootsnap-1.1.7/lib/bootsnap/load_path_cache/core_ext/active_support.rb:53:in `block in load_missing_constant': uninitialized constant Sidekiq::CLI (NameError)
from /home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/bootsnap-1.1.7/lib/bootsnap/load_path_cache/core_ext/active_support.rb:8:in `without_bootsnap_cache'
from /home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/bootsnap-1.1.7/lib/bootsnap/load_path_cache/core_ext/active_support.rb:53:in `rescue in load_missing_constant'
from /home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/bootsnap-1.1.7/lib/bootsnap/load_path_cache/core_ext/active_support.rb:42:in `load_missing_constant'
from /home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.0.5/lib/sidekiq/launcher.rb:65:in `heartbeat'
from /home/travis/build/rails/rails/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.0.5/lib/sidekiq/launcher.rb:123:in `start_heartbeat'
```
https://travis-ci.org/rails/rails/jobs/317187279#L2152
The reason for this is that `Sidekiq::CLI` has not been loaded.
Sidekiq integration test launches a Sidekiq instance within
another Ruby process. In such a case, need to require 'sidekiq/cli'
in that launch code.
Ref: https://github.com/mperham/sidekiq/pull/3692#issuecomment-352032251
`BigDecimal.new` has been deprecated in BigDecimal 1.3.3
which will be a default for Ruby 2.5.
Refer
533737338d
* This commit has been made as follows:
```
cd rails
git grep -l BigDecimal.new | grep -v guides/source/5_0_release_notes.md | grep -v activesupport/test/xml_mini_test.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g"
```
- `activesupport/test/xml_mini_test.rb`
Editmanually to remove `.new` and `::`
- guides/source/5_0_release_notes.md
This is a Rails 5.0 release notes.
ActiveJob wraps every adapter into its own class, that is later passed
into DelayedJob which is responsible for displaying all the logs.
This change improves the logging so we can easily trace executed
jobs and see meaningful information in the logs.
Omit `rails activestorage:install` for jdbcmysql, jdbc and shebang tests
AppGeneratorTest#test_config_jdbcmysql_database
rails aborted!
LoadError: Could not load 'active_record/connection_adapters/mysql_adapter'.
Make sure that the adapter in config/database.yml is valid.
If you use an adapter other than 'mysql2', 'postgresql' or 'sqlite3' add
the necessary adapter gem to the Gemfile.
(compressed)
bin/rails:4:in `<main>'
Tasks: TOP => activestorage:install => environment
(See full trace by running task with --trace)
AppGeneratorTest#test_config_jdbc_database
rails aborted!
LoadError: Could not load 'active_record/connection_adapters/jdbc_adapter'.
Make sure that the adapter in config/database.yml is valid.
If you use an adapter other than 'mysql2', 'postgresql' or 'sqlite3' add
the necessary adapter gem to the Gemfile.
(compressed)
bin/rails:4:in `<main>'
Tasks: TOP => activestorage:install => environment
(See full trace by running task with --trace)
AppGeneratorTest#test_shebang_is_added_to_rails_file
/home/ubuntu/.rbenv/versions/2.4.1/bin/ruby: no Ruby script found in input (LoadError)
Prevent PendingMigrationError in tests
* Run `bin/rails db:migrate RAILS_ENV=test` in test_cases before start tests to prevent PendingMigrationError
* FileUtils.rm_r("db/migrate")
* --skip-active-storage
Fix failed tests in `railties/test/railties/engine_test.rb`
Related to #30111
Imporve `SharedGeneratorTests#test_default_frameworks_are_required_when_others_are_removed`
- Explicitly skip active_storage
- Ensure that skipped frameworks are commented
- Ensure that default frameworks are not commented
Fix error `Errno::ENOSPC: No space left on device - sendfile`
Since `rails new` runs `rails active_storage:install`
that boots an app.
Since adding Bootsnap 0312a5c67e35b960e33677b5358c539f1047e4e1
during booting an app, it creates the cache:
264K tmp/cache/bootsnap-load-path-cache
27M tmp/cache/bootsnap-compile-cache
* teardown_app must remove app
* Use `gem 'redis', '~> 4.0'` for new app Gemfiles
* Loosen Action Cable redis-rb dep to `>= 3.3, < 5`
* Bump redis-namespace for looser Redis version dep
* Avoid using the underlying `redis.client` directly
* Use `Redis.new` instead of `Redis.connect`
Since f55ecc6, the integration test of sidekiq and resque is not working
in CI.
https://travis-ci.org/rails/rails/jobs/251783876
Because f55ecc6 required a password to access redis.
Therefore, handling by passing passwords when connecting to redis.
Active Job logging instrumentation is changed to log errors (with
backtrace) when a job raises an exception in #perform. This improves
debugging during development and test with the default configuration.
Prior to Rails 5, the default development configuration ran jobs with
InlineAdapter, which would raise exceptions to the caller and be
shown in the development log. In Rails 5, the default adapter was
changed to AsyncAdapter, which would silently swallow exceptions
and log a "Performed SomeJob from Async..." info message. This could
be confusing to a developer, as it would seem that the job was
performed successfully.
This patch removes the "Performed..." info message from the log
and adds an error-level "Error performing SomeJob..." log message
which includes the exception backtrace for jobs that raise an
exception within the #perform method. It provides this behavior for
all adapters.
Currently we provide the Job ID in logs only related to enqueuing a job.
This adds the job id to the remaining ActiveJob logs when:
- a job started performing
- a job ended performing
Providing the job id in those logs will ease searching logs by job id.
The `ActiveJob::TestHelper` replace the adapter to test adapter in
`before_setup`. It gets the target class using the `descendants`, but if
the test target job class is not loaded, will not be a replacement of
the adapter.
Therefore, instead of replacing with `before_setup`, modified to
replace when setting adapter.
Fixes#26360
Currently, backburner integration test is not running on CI.
https://travis-ci.org/rails/rails/jobs/196005322#L610
Using `Backburner::Worker.connection` to check whether beanstalkd is
running. But `Backburner::Worker.connection` was removed in backburner
1.2.0.
81fde499c2
Therefore, this check process always becomes false, so the test is no
longer done. I fixed it so that check processing is done correctly.
This will fix issues in [resque-scheduler](https://github.com/resque/resque-scheduler) `#job_to_hash` method,
so we can use `#enqueue_delayed_selection`, `#remove_delayed` method in resque-scheduler smoothly.
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
test.
This PR adds a method called `queue_adapter_for_test` to
`ActiveJob::TestHelper`. This method is expected to provide the queue
adapter to be used for jobs under test. It maintains the current
behaviour by defaulting to an instance of
`ActiveJob::QueueAdapter::TestAdapter`. Tests that include
`ActiveJob::TestHelper` or extend from `ActiveJob::TestCase` can provide
a custom queue adapter by overriding `queue_adapter_for_test` in their
class.
- Added tests for checking all reserved hash keys of ActiveJob::Arguments.
- Moved unrelated code from the test to the correct place, i.e. newly created
test.
Placing non-native JSON data types, like symbols, in the hash to serialize means that the deserialize method will return something different from what was serialized, a common bug and source of frustration for devs.
On most filesystems file ctime is limited to 1 second granularity, which means that on
faster computers multiple simple jobs (for instance dummy TestJob) can finish within the
same second.
The execution order test in ActiveJob integration tests relies on multiple TestJobs
writing files then comparing the ctime. As a result integration tests would sometimes
fail as the ctime of the files written by these TestJobs could have coincidental ctimes
making the comparison for job order fail.
This commit adds a far more precise execution time (to the extent that the Ruby Time
class allows) to the file created by TestJob, and updates the execution order assertion
to use it, removing the race condition.
The INITIAL_WAIT constant has moved to the Sidekiq::Poller class but
rather than setting the constant directly we can override it via the
`:poll_interval_average` option.
This was causing random build failures because the test was waiting
for 10 seconds for the job to execute but the initial wait was a
random value between 10 and 15 seconds.
If db/schema.rb doesn't exist then we get warnings from the dummy Rails
application so run it for all adapters even if they're not using the
database to store jobs.
Currently the log returned by running ActiveJob tests is filled with:
> DEPRECATION WARNING: Returning `false` in a callback will not implicitly halt a callback chain in the next release of Rails. To explicitly halt a callback chain, please use `throw :abort` instead.
For instance, see https://travis-ci.org/rails/rails/builds/77978273
This happens because some setup and teardown methods [like these one](https://github.com/rails/rails/blob/master/activejob/test/cases/async_job_test.rb#L10-L17)
invoke other methods like `perform_asynchronously!` that can return `false`, but
not with the intention of halting the process if they do.
In my opinion, these deprecation warnings can be silenced to have
the log result cleaner (especially when browsing for errors).
this removes the following warning:
```
DEPRECATION: `config.poll_interval = 0.5` will be removed in Sidekiq 4. Please update to `config.average_scheduled_poll_interval = 0.5`.
```
As described in the "Follow Coding Conventions" section in our
contribution guide (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions)
we favor `assert_not` over `refute`.
While we don't usually make stylistic changes on it's own I opted to do
it in this case. The reason being that test cases are usually copied as
a starting point for new tests. This results in a spread of `refute` in
files that have been using it already.
When `#perform_later` is called the locale isn't stored on the
queue, which results in a locale reset when the job is performed.
An example of the problem:
I18n.locale = 'de'
HelloJob.perform_now # german message, correct
but
I18n.locale = 'de'
HelloJob.perform_later # english message, incorrect
This PR attaches the current I18n.locale to every job during the
serialization process. It is then restored during deserialization
and used to perform the job with the correct locale.
It falls back to the default locale if no serialized locale is
found in order to provide backward compatibility with previously
stored jobs. It is not necessary to clear the queue for the update.
When a job is added to Sidekiq by ActiveJob, make sure we still can get the
original job_id provider by Sidekiq. We do this by adding the sidekiq jid to
provider_job_id field on the job object.
Partly fixes#18821
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
That seems to be a bug, but as we don't actually care about the
precision for our test, we'll just give it a bit longer.
[Matthew Draper & Cristian Bica]
setup gets called from the initializer, so it happens more than once in
a test run. Trying to drop the database again after the first process is
connected is.. ineffective. And entirely pointless.
Instead, defer creating the database to start_workers -- which only
happens once, right before we start doing anything real.
