Expose retries_count on Racecar::Message

[Alexander-Blair]

In a recent PR, support was added to provide retries_count to the instrumentation payload, in order to define custom behaviours on error handling. However, this does not allow us to drive the consumer's behaviour based on the retries, if required.

Example usage:

• We're consuming from a topic where we don't absolutely need to process every single update successfully, however we want to allow for a few intermittent failures

class SemiImportantConsumer < Racecar::Consumer
  MAX_RETRIES_COUNT = 5

  subscribes_to "semi_important_topic"

  def process(message)
    data = JSON.parse(message.value)

    do_some_stuff(data)
  rescue StandardError => e
    raise e if message.retries_count < MAX_RETRIES_COUNT

    Honeybadger.notify(e)
    Logger.error("Oh no we ran out of retries")
    ... etc
  end
end

[dasch]

Makes sense 👍

[Alexander-Blair]

Thanks @dasch ! If you are still interested in looking at the concurrent processing (detailed in #188), would be happy to help out where I can

[dasch]

@Alexander-Blair that would be great! Let me know if you'd like some pointers. There's also the ruby-kafka Slack if you'd prefer that.

[dasch]

(or the new, fancy Discussions here on GH!)