Add dynamic cooldown policies

[ixti]

Allow Config#cooldown_period and Config#cooldown_threshold to be specified as Proc:

Sidekiq::Throttled.configure do |c|
  c.cooldown_period = lambda do |queue_name|
    queue_name == "default" ? 2.0 : 10.0
  end

  c.cooldown_threshold = lambda do |queue_name|
    queue_name == "mostly-throttled" ? 0 : 10
  end
end

This will go very well in pair with planned push-back strategies PR.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.69%. Comparing base (27ec05e) to head (01b769d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #174   +/-   ##
=======================================
  Coverage   98.69%   98.69%           
=======================================
  Files          19       19           
  Lines         460      461    +1     
  Branches       77       77           
=======================================
+ Hits          454      455    +1     
  Misses          6        6           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[freemanoid]

  c.cooldown_period = lambda do |unit_of_work|

I'm not sure about the unit_of_work in the interface. Maybe a queue name would be enough? I'm just thinking about how it can be done in a bit more explicit fashion.

[ixti]

I'm not sure about the unit_of_work in the interface. Maybe a queue name would be enough? I'm just thinking about how it can be done in a bit more explicit fashion.

My rationale behind unit of work was that one may want to have different period/threshold based on job class and/or args. I guess the most straight-forward API in this case will be:

c.cooldown_period = lambda do |queue_name, message|
  job_record = Sidekiq::JobRecord.new(message)

  if job_record.display_class == "FooJob"
    1.0
  elsif "default" == queue_name
    2.0
  else
    3.0
  end
end

Naturally, in this case, it will also support:

c.cooldown_period = lambda do |queue_name|
  if "default" == queue_name
    2.0
  else
    3.0
  end
end

[ixti]

After giving it another thought, I think we can keep it simple :D just queue name.

[freemanoid]

After giving it another thought, I think we can keep it simple :D just queue name.

I like the Sidekiq::JobRecord idea tho. 😄

[ixti]

I like the Sidekiq::JobRecord idea tho. 😄

I do like it too. But it will involve object creation even when user does not need it (e.g. just caring about queue_name. Thus passing queue_name where the message arrived from and message give full flexibility without sacrificing performance.

[ixti]

I'm inclined towards do |queue, message| approach.

[ixti]

Will wait with final decision until real case scenario appears.