Sentry-ruby: Raven.annotate_exception has no equivalent in sentry-ruby

[fsateler]

Describe the bug

When migrating from sentry-raven to sentry-ruby, there appears to be no equivalent to Raven.annotate_exception. It is not mentioned on the migration guide either. What is the new way to add extra info to an exception?

Environment

• Ruby Version: 2.6
• SDK Version: 4.1.4
• Integration Versions (if any):
  
  
  
  • Rails 6.0
  
  

[st0012]

@fsateler because annotate_exception was a Ruby-only API, currently we don't support anything similar to it after we unify the APIs with other SDKs. would you mind providing me some use cases so I can find a replacement for it?

[fsateler]

The use case is being able to attach extra info about the exception, near the place where it was generated, but far from the place where it is handled. For example:

class ProcessMultipleItemsJob < ApplicationJob
  def perform
     Item.find_each do |item|
        ProcessItem.call(item)
     end
  end
end

class ProcessItem
  def call item
    item_context = build_context(item)
    # do something
  rescue => e
    # Here we have important context infomation, but we don't want to actually handle the exception. 
    # we let the ActiveJob integration handle it
    Raven.annotate_exception(e, extra: { item_formula: item.formula, item_context: item_context })
   raise
  end

  private def build_context item
    # build the context
  end
end

[kaspergrubbe]

@swistak35 If I remember correctly you also used #annotate_exception quite heavily in our setup, can you provide some examples too?

[swistak35]

@kaspergrubbe We have been using Raven.extra_context and Raven.user_context to add the context to the errors.

[st0012]

@fsateler thanks for the example. but I think this should work the same:

  def call item
    item_context = build_context(item)
    # do something
  rescue => e
    Sentry.set_extras(item_formula: item.formula, item_context: item_context)
    raise
  end

[fsateler]

@st0012 that could work! But only in the case there are no nested scopes (otherwise if the error "escapes" the inner scope, the extra context would be lost). But I figure a regular rails app should not have nested scopes unless the app developer created one, right?