sidekiq_options doesn't seem to work with Active job.

[arafatkatze]

Ruby version: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin18]
Sidekiq / Pro / Enterprise version(s): 6.0.0
ActiveJob Version: 5.2.3

I am not sure if I should raise this issue here or in the active job repo but in the docs here It is mentioned that

I can't seem to find a 6.0.1 version so maybe this is a future goal. But since I could use this method with my code, I decided to try it out and it doesn't seem to work for me.
The retry strategy just goes back to the default retry strategy with 25 retries.

I can't seem to figure out how to debug the issues with my jobs so I put a debug statement here
where I get

#{opts} = {retry: 3} 

I also put in another debug statement here

where I get

 #{worker.class.get_sidekiq_options} =  {"retry"=>true, "queue"=>"default"}       

 #{worker} = #<ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper:0x00007fe1e0e30228>

So it seems to me that the sidekiq_options_hash isn't the same in between here and here

I couldn't trace the changes any further. The main reason I used this was because I was using the retry_on method in active job and that doesn't seem to work either(This method too changes the retry strategy to default silently and my jobs keep retrying for 25 times exponentially).

I guess the issue that I am facing comes back to what is described in this comment.

I already have a work around for this(Using resque_from) so my issue is solved but I just wanted to figure out why this isn't working.

Is this a known issue or is something wrong with my configuration?
Should this issue be raised in ActiveJob too?

[arafatkatze]

Just to be clear, I understand that you do not control activejob so it's probably not a good idea to ask this question to you but I only asked because I saw this in the documentation(which mentions compatibility with activejob) and I figured that I might get some insights from raising this issue here.

Thanks a lot.

[mperham]

Use master.

…

On Sep 21, 2019, at 17:35, Arafat ***@***.***> wrote: Just to be clear, I understand that you do not control activejob so it's probably not a good idea to ask this question to you but I only asked because I saw this in the documentation(which mentions compatibility with activejob) and I figured that I might get some insights from raising this issue here. Thanks a lot. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mperham]

Oh and you need Rails master too, it needs Rails 6.0.1.

…

On Sep 21, 2019, at 17:58, Mike Perham ***@***.***> wrote: Use master. > On Sep 21, 2019, at 17:35, Arafat ***@***.***> wrote: > > Just to be clear, I understand that you do not control activejob so it's probably not a good idea to ask this question to you but I only asked because I saw this in the documentation(which mentions compatibility with activejob) and I figured that I might get some insights from raising this issue here. > > Thanks a lot. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread.

[arafatkatze]

Thanks a lot for the fast comment.
I am using things in a production environment so I guess I will have to wait for an official release.
Can you tell me when we might have an official release?

[mperham]

I don’t know when Rails 6.0.1 will be released. It won’t work until then.

…

On Sep 21, 2019, at 18:16, Arafat ***@***.***> wrote: Thanks for the comment. I am using things in a production environment so I guess I will have to wait for an official release. Can you tell me when we might have an official release? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jaimerson]

This still seems to be the case on Rails with this patch. retry option, sidekiq_retry_in_block (see) and sidekiq_retries_exhausted_block (see) all seem to be ignored in favor of worker (which in ActiveJob's case would be JobWrapper) instead of msg['wrapped'].

Rails 6.0.0 (+patch)
Sidekiq 6.0.2
Sidekiq-ent 2.0.0
Sidekiq-pro 5.0.1

[jaimerson]

@mperham can you confirm this is the case? I managed to get it working by patching JobRetry. So unless I'm missing something there are some changes required. I can send a PR if that's the case.

[mperham]

@jaimerson The retry blocks will not work but the changelog didn't say that. sidekiq_options, including retry, will work.

[jaimerson]

@mperham would you like me to submit a PR for them to work? I mean, since it's available in the ActiveJob API it's intuitive that it should work.

[mperham]

No, I don't like those block features and regret adding them.

[pirj]

Update: support code will only make it to Rails 6.0.2 rails/rails#37214 (comment)

[fotinakis]

@mperham Any ideas why sidekiq_options doesn't seem to work with ActiveJob on this setup?

rails 6.1.5.1
sidekiq 6.4.2
sidekiq-pro 5.3.1

class TestJob < ActiveJob::Base
  sidekiq_options queue: :low_priority

  def perform
    true
  end
end

Then running it, you see it enqueue on the default queue and not low_priority:

TestJob.perform_later

[ActiveJob] [TestJob] [...] Performing TestJob (Job ID: ...) from Sidekiq(default) enqueued at ...

(I'm actually asking about sidekiq_options pool: support, but simplified this example to just any option)

[mperham]

@fotinakis I don't believe AJ supports the pool option. That's implemented in Sidekiq::Job.

[fotinakis]

@mperham ok thanks — so to confirm, there is no way to get an ActiveJob to pass a pool option through? The job must be converted to a native Sidekiq::Job?

[mperham]

Correct.

…

On Wed, Jun 22, 2022 at 16:54 Mike Fotinakis ***@***.***> wrote: @mperham <https://github.com/mperham> ok thanks — so to confirm, there is no way to get an ActiveJob to pass a pool option through? The job must be converted to a native Sidekiq::Job? — Reply to this email directly, view it on GitHub <#4281 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAWX6WVTLARBPRSG5LKGDVQMSJPANCNFSM4IZAQPCA> . You are receiving this because you were mentioned.Message ID: ***@***.***>