Add singleton class extension support to Bugsnag::Middleware::ExceptionMetaData

[jnraine]

Using Bugsnag::MetaData to attach metadata or other Bugsnag-specific data directly to an exception class works great for the common case:

class MySpecialError < StandardError
  include Bugsnag::MetaData
end

# when something breaks
error = MySpecialError.new("Oh no!")
error.bugsnag_meta_data = {foo: :bar}

However, it doesn't support dynamically extending an exception class at runtime.

begin
  do_a_thing
rescue => e
  e.extend(Bugsnag::MetaData)       # extend singleton class
  e.bugsnag_meta_data = {foo: :bar} # add context
  raise e                           # re-raise, let other code send to Bugsnag
end

This used to work in Bugsnag 5.1.0 but broke when a type check was added in 6.0.0:

bugsnag-ruby/lib/bugsnag/middleware/exception_meta_data.rb

Line 10 in 94cea31

if exception.class.include?(Bugsnag::MetaData)

This pull request changes the implementation to use respond_to? over a type check. This supports the singleton class case above and any other case we've forgotten to handle. For example, a developer need not include Bugsnag::MetaData directly, they need only to define the bugsnag_meta_data method and Bugsnag::Middleware::ExceptionMetaData will pick up the data.

This change also applies to bugsnag_user_id, bugsnag_context, and bugsnag_grouping_hash.

Note: originally, I fixed my issue with a change to the type check – exception.is_a?(Bugsnag::MetaData) – which handles class and singleton class extension. After thinking on it for a bit and noticing that the code used to rely on respond_to?, I decided to go that route instead.

[jnraine]

Coveralls thinks coverage went down but given the changeset I'm not sure how that's possible. If you'd like me to add other specs, let me know.

[jnraine]

@Cawllec would you be able to review this?

[kattrali]

Thanks @jnraine for the contribution.

[jnraine]

Thanks for merging! When do you expect to cut another gem release?

[kattrali]

Released in v6.6.4