1
0
Fork 0
mirror of https://github.com/mperham/sidekiq.git synced 2022-11-09 13:52:34 -05:00
Commit graph

18 commits

Author SHA1 Message Date
Samwise Wang
6b14010199 Fix the error in worker#perform_in about interval type (#3170)
Situation:
We are using Sidekiq Pro with ActiveSupport.
When I passed a object which is ActiveSupport::TimeWithZone to perform_at,
`TypeError: can't convert ActiveSupport::TimeWithZone into an exact
number` has occurred.

Problem:
Time can't plus a ActiveSupport::TimeWithZone object.

Solution:
We can transform any Time object to float, and use it to compare and
calculate.
2016-09-30 02:31:08 -07:00
Mike Perham
2c9f7662fc Freeze all string literals in source, fixes #2741
Tests pass and smoke test works perfectly.
2015-12-31 15:33:35 -08:00
Mike Perham
20b6e2f837 fix test break 2015-09-23 16:21:25 -07:00
Mike Perham
53e6b9e2df Test suite overhaul
Remove Redis mocking.  Minimize Redis flushing where possible.
2015-09-23 10:56:37 -07:00
Albert Llop
224cfe575c Use created_at for the time schedule jobs are scheduled
When a job is scheduled, it should have a created_at time, and get a
enqueued_at when it's actually enqueued back into a queue.
2015-06-03 19:28:41 +02:00
David Stosik
a2dd36c6d1 MyWorker.perform_in(1.month) does not always schedule job in one month.
At the moment, `MyWorker.perform_in(1.month)` always schedules a job in 30
days. When added to a date, `1.month` will add 1 to the date's month count,
which means that it will add 28, 29, 30, or 31 days depending on the month and
year.
When I call `MyWorker.perform_in(1.month)`, I would expect the job to be
scheduled next month, same day of the month, all the time. At the moment, it is
true only four months in the year.
My pull request tries to fix this by converting the interval object to a Float
at the last possible moment.
Plaese note that the test I wrote will fail only during months that do not have
30 days. Ideally, I would add a dependency to Timecop and freeze time to any
day in a month of 28, 29 or 31 days. This could also avoid using
`#assert_in_delta`, in favour of `#assert_equal`.

Feel free to read my blog post [Rails' `1.month` has a variable
length](http://dstosik.github.io/rails/2015/02/19/rails-1month-variable-length/)
for more details.
2015-02-20 09:36:32 +09:00
grosser
57a06d00d6 allow every test to be run with just ruby test/xxx_test.rb 2014-12-30 12:54:58 -08:00
Mike Perham
77c57675ec Fix build 2014-05-13 14:00:20 -07:00
Jonathan Hyman
5e2b691ac8 Lets you inject in a RedisConnect into Sidekiq::Client so you can push jobs to different Redis instances in the same application. 2014-03-24 13:20:16 -04:00
Aaron Ackerman
88073bd2d2 Normalize queue name to string when pushing a job 2013-11-14 21:12:27 -06:00
Rafal Wojsznis
9eac92a7c0 Add enqueue_to_in and enqueue_in methods on Sidekiq::Client class 2013-09-29 10:04:56 +02:00
Mike Perham
babfdc96c5 Backport test suite to Minitest 4 so we can test against Rails 4. 2013-09-22 14:38:33 -07:00
Mike Perham
4679c95f49 Upgrade to Minitest 5 2013-05-12 14:25:30 -07:00
Mike Perham
9360c01aad client api refactoring 2013-03-24 17:42:43 -07:00
Mike Ragalie
8028eda89a Support scheduled jobs in bulk push 2012-11-19 21:31:14 -08:00
Mike Perham
ae2837bd86 Add unique job ID for every pushed job 2012-08-11 11:47:25 -07:00
Jason Staten
b3249eb503 Handle Redis#zadd return value correctly
Redis#zadd will return a boolean value when only one item is added. This
was failing to be equal to 1, and caused any Sidekiq::Client::push
invocations with an 'at' value to return false, even if they
successfully were stored into redis.
2012-06-20 16:24:23 -06:00
Mike Perham
2c4be4cada Scheduled jobs! Bump to 2.0.0.
Performs can now be scheduled at arbitrary points in the future.
2012-05-25 20:21:42 -07:00