sidekiq-cron: Broken job arguments after updating to 1.7 version (extra timestamp argument for jobs taking 0 arguments)

I can second this issue as well. Now we’re getting the following error when using it:

ArgumentError wrong number of arguments (given 1, expected 0)

And taking one of the errors of ours as example, the array below represents the arguments it received while it wasn’t expecting any arguments:

[1658897402.8730807]

@Azdaroth @leandro if like us you upgrade to 1.7.0 before realising the new argument, then I would recommend you to delete all your existing cron jobs and restart sidekiq. This will then recreate the job now setting correctly the date_as_argument as false.

I think, if like us you deployed the code before setting the date_as_argument: to false then the jobs were now set in stone with this a lingering argument.

Hello.

I also faced this problem and found the possible cause.

Verification environment

• New version of sidekiq-cron: 1.9.1
• Old version of sidekiq-cron: 1.6.0

After some trial and error, I found that this problem is caused by the following behavior

1. newer version of sidekiq-cron registers jobs with date_as_argument option

irb(main):002:0> conn = Sidekiq.redis { |conn| conn }
irb(main):003:0> pp conn.hgetall("cron_job:10")
{"date_as_argument"=>"0",
 "description"=>"",
 "active_job"=>"false",
 "status"=>"enabled",
 "queue_name_prefix"=>"",
 "symbolize_args"=>"false",
 "message"=>
  "{\"queue\"\"default\",\"class\":\"YourGreatJob\",\"args\":[]}",
 "last_enqueue_time"=>"2023-01-30 10:40:35 +0000",
 "cron"=>"30 * * * *",
 "queue_name_delimiter"=>"",
 "klass"=>"YourGreatJob",
 "name"=>"10",
 "args"=>"[]"}

1. Our application is deployed using a rolling update (https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html) method. So, There is a temporary time when new and old sidekiq processes are connected to the same redis. In this case, if a sidekiq 1.6.0 sidekiq process executes a job with this new option, it will not be processed properly

It seems that args["date_as_argument"] becomes "0" and is evaluated as true at the following location at sidekiq-cron 1.6.0

https://github.com/sidekiq-cron/sidekiq-cron/blob/v1.6.0/lib/sidekiq/cron/job.rb#L282

I’ll try to submit a modified PR.

Ok I can confirm that, once updated to 1.7.0 even if you revert back to 1.6.0 the jobs will still send the extra param.

To fix this, we’ve deleted the old jobs, and restarted Sidekiq that then re created the new jobs with the 1.6.0 gem loaded.

FYI: I have already applied the changes to https://github.com/sidekiq-cron/sidekiq-cron/issues/350#issuecomment-1412892389 in my development environment and deployed multiple times, and have confirmed that the errors that used to appear no longer occur!

Hello everybody 👋🏼

Thanks to @mkusaka (#392) we have now a potential fix!

Please, if you can test this branch in your app and report back, that would be really helpful to release a new version:

gem 'sidekiq-cron', github: 'mkusaka/sidekiq-cron', branch: 'patch'

It wasn’t quite clear from the above comments but from what I can tell, 1.7.0 ignores date_as_argument in your config and sends the additional date parameter to the perform method anyway.

After downgrading to 1.6.0, the @date_as_argument=false had disappeared from my jobs, but the argument was then defined explicitly: @args=[1660264240.1838207].

As @nicalpi suggested, destroying and recreating my jobs cleared this arg. This is the command I used:

Sidekiq::Cron::Job.destroy_all!
Sidekiq::Cron::Job.load_from_hash YAML.load_file('path/to/my_schedule.yml')

Once this was done, I checked my jobs and I see the argument is gone: @args=[].

Note that if you have retries set to true, then you may have a lot of retries still scheduled and you will still see errors coming through. In my case I had days worth of retries which I had to go and kill off. I need to review whether I should really have any of my tasks set to retry: true, but that is nothing to do with this issue.

I’ve downgraded back to 1.4.0 for now as I don’t want to take any chances when I push this into production.