Kevin Robell

It'd be great if it was the default behavior. I was just thinking about backwards compatibility when I suggested a config flag there. Either way works for me.

It does warn for some but not all invalid cron lines. Currently, it will raise an error if it's unable to parse a cron expression from a string. It will...

Yeah, I hadn't considered that. I guess I'd like to keep the natural syntax and have stricter evaluation at the same time but `Fugit.do_parse` allows for durations which doesn't work...

The only work around I can think of is to do something like this. ```rb @parsed_cron ||= if strict? cron = Fugit.parse_cron(@cron) || Fugit.parse_nat(@cron, :multi => :fail) raise ArgumentError, "invalid...

> Working with a set of specs would help (me at least). Once a level of clarity has been established, a solution can be derived and sustained. What comes in?...

It looks like one reason I'd never heard of `fail` before is that it gets automatically corrected to `raise` by RuboCop as of 2015. I'm not sure I agree with...

This still seems to be an issue as of RuboCop `v1.55.1`.

So this would overwrite the existing and/or default retry settings set for a job just like happens currently with the queue setting?

The simplest thing would be to just add a `cron_process_count` configuration option and then override the `process_count` method in the `Sidekiq::Cron::Poller` class. ```rb def process_count @config[:cron_process_count] || super end ```...