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.
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.
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]
Requiring sidekiq/testing changes stuff, so we need to counteract that
after we do so.
And given its potential to confuse things, let's do it up front, at a
predictable point.
Sidekiq logs the name of the job class being performed. Because
ActiveJob wraps the class, this means every job logs as an AJ::JobWrapper
instead of the actual class name.
Will help fixmperham/sidekiq#2248
