Make sure cursor is a keyword argument

[GustavoCaso]

We found cases of people using cursor argument, not as a keyword argument.

This can lead to unexpected behaviour.

Discourse ticket

This change introduces an extra level of checking so when running the
job, we make sure the signature of build_enumerator has the cursor keyword
argument

@Shopify/job-patterns

[BoGs]

TIL

[djmortonShopify]

Wouldn't this be slightly simpler?

    parameters.each do |parameter_type, parameter_name|
      next unless parameter_name == :cursor
      return true if parameter_type == :keyreq
    end
    false
  end

[djmortonShopify]

each_iteration_will_not_raise but the test has an assert_raises(ArgumentError)

[kirs]

Thanks for making it a better experience!

[kirs]

This is not strictly related to your PR or needs addressing, but it's somewhat pointless to check for arguments and the method signature on every perform of a job. Once a job class has been validated, we know it implements methods right. This makes me believe that we should be skipping assert_implements_methods! for classes that has already been validated.

[GustavoCaso]

That is a great point, we could have a local cache of checked classes and avoid having to call assert_implements_methods! unnecessary. I will explore this on another PR.

[kirs]

Nitpick: please make sure that this condition is met may not be the language that's typically used in exception messages. "expects the keyword argument cursor" is probably enough for developers to understand that's a condition that they have to satisfy :)

[kirs]

Looks like method(:build_enumerator).parameters doesn't carry much performance overhead:

require 'benchmark/ips'

def build_enumerator
end

Benchmark.ips do |x|
  x.config(:time => 3, :warmup => 1)

  x.report("respond_to") do
    respond_to?(:build_enumerator)
  end
  x.report("respond_to + parameters") do
    respond_to?(:build_enumerator) && method(:build_enumerator).parameters
  end

  x.compare!
end

Warming up --------------------------------------
          respond_to   270.254k i/100ms
respond_to + parameters
                       264.253k i/100ms
Calculating -------------------------------------
          respond_to      8.025M (± 2.1%) i/s -     24.323M in   3.032362s
respond_to + parameters
                          8.136M (± 3.2%) i/s -     24.576M in   3.024205s

Comparison:
respond_to + parameters:  8135920.7 i/s
          respond_to:  8024793.9 i/s - same-ish: difference falls within error