Only throttle if parameter meets condition

[dbenjamin57]

Hi there, I was wondering if there was an option to throttle only if a param meets a certain condition.

Lets say for example I have Worker A:

class AWorker
include Sidekiq::Worker
def perform(some_param)
end
end

Now I only want to throttle the worker if some_param == "aaa" but not if some_param == anything else.
Is that a supported option the gem can handle? If so, how?

Cheers,
Dan

[ixti]

it's not "supported" directly, but you can "workaround" that by:

class MyWorker
  include Sidekiq::Worker
  include Sidekiq::Throttled::Worker

  sidekiq_throttle(:concurrency => {
    # technically it's till throttling but using next to *more than enough* limit
    :limit => -> (user_id) { 1 == user_id ? 123_456_789 : 1_000 }
  })
end

We can improve API of Sidekiq::Throttled so that will not throttle if limit block returns nil. But I find that API pretty bad. IMHO in your case the best options would be:

class MyWorker
  include Sidekiq::Worker

  def perform(some_param)
    # ...
  end
end

class MyWorker::Throttled < MyWorker
  include Sidekiq::Throttled::Worker

  sidekiq_throttle :concurrency => { :limit => 1_000 }
end

[erated]

"We can improve API of Sidekiq::Throttled so that will not throttle if limit block returns nil. But I find that API pretty bad"

I actually like that approach. Why not go that route? The second option requires the users of the gem to create "ugly workarounds" just to support something that should be quite basic in terms of throttling.

not throttling if the deciding param is nil in my opinion is the cleanest solution.

[ixti]

I did not said we won't go that way. I just said that I find it bad. I find dynamic throttling support we have bad as well, because it adds unneeded complexity. Any dynamically changed dependency in job's workflow makes it harder to debug. Proposed way of having separate class makes it simple and easy to figure out which part exactly fails.

[ixti]

In any case, PRs are welcome. :D

[ixti]

@erated, @dbenjamin57 see #31 (gonna merge and release as 0.7.1 this week)