error handler will fail if retry block is empty

[caljess599]

I was attempting to use the config.error_handler block as documented in the README, but it turns out that if you hit a 429 with this code:

config.error_handler = {
    [429, 430, 442] => { max_retries: 5, seconds_delay: 1 },
    (500..530).to_a => { max_retries: 2, seconds_delay: 2 },
    400 => { max_retries: 3, seconds_delay: 3 },
  }

you will end up with a blank retry_block and that will cause a NoMethod (on a nil) error, and so game over--no sleep, just exit.

I solved this problem with borrowing code for the 429 error from a test in the code base that specified the retry_block:

429 => {
          max_retries: 2,
          seconds_delay: 10,
          retry_block: -> () { puts 'API returned 429 Status Code. Sleeping...' }
        },

Hard to say whether the fix here is to improve the (already noted as lacking) documentation or to not allow that retry_block to be empty, no matter what someone specifies in their config... but this cost me a bit of time so I figured I'd report it.

[jacobjlevine]

Hey @caljess599, have you actually seen evidence that the retries are working? I've been doing testing, and I'm not seeing any evidence of it. And I also haven't seen any evidence in the codebase that the gem actually retries failed API calls. It almost seems like the architects of this gem created the configuration endpoint without actually implementing it. But maybe I'm missing something?