Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global event processors do not clear on Sentry.init #2051

Closed
andrewharrisatcheckr opened this issue Jun 2, 2023 · 3 comments · Fixed by #2342
Closed

Global event processors do not clear on Sentry.init #2051

andrewharrisatcheckr opened this issue Jun 2, 2023 · 3 comments · Fixed by #2342
Assignees

Comments

@andrewharrisatcheckr
Copy link

Issue Description

Hello! In working recently with sentry-ruby, a colleague and I found that the recently added global event processors from #1974 don't seem to clear on invocation of Sentry.init. This is a bit unexpected, considering the overall action of Sentry.init to reset other options.

If this is the intended behavior and simply could use a documentation note, then please feel free to close this issue report.

Reproduction Steps

  1. Sentry.init to get started
  2. Sentry.add_global_event_processor
  3. Sentry.init to reset state
  4. Sentry.add_global_event_processor
  5. Examine Sentry::Scope.global_event_processors.length or similar

For example:

Gemfile

# frozen_string_literal: true

source 'https://rubygems.org'

gem 'rspec'
gem 'rubocop'
gem 'sentry-ruby', '~> 5.9'

spec/sentry_ruby_spec.rb

# frozen_string_literal: true

require 'rspec'
require 'sentry-ruby'

describe Sentry do
  it 'flushes global event processors on .init' do
    # Setup - init and set one global event processor
    Sentry.init
    Sentry.add_global_event_processor do |event, _hint|
      event.tags = { foo: 42 }
      event
    end
    expect(Sentry::Scope.global_event_processors.length).to eq(1)

    # When - init and set another global event processor
    Sentry.init
    Sentry.add_global_event_processor do |event, _hint|
      event.tags = { foo: 42 }
      event
    end

    # Then there should be one global event processor.
    expect(Sentry::Scope.global_event_processors.length).to eq(1)
    # However, this fails: length is 2, because Sentry.init retains global event processors.
  end
end

Expected Behavior

Sentry::Scope.global_event_processors.length shows one configured global event processor.

Actual Behavior

Sentry::Scope.global_event_processors.length shows two configured global event processors.

Ruby Version

3.2.2

SDK Version

5.9.0

Integration and Its Version

Non-specific

Sentry Config

None needed. Works with sentry-ruby defaults.

@sl0thentr0py
Copy link
Member

I can remove them on Sentry.close but I don't think init should remove them.

@andrewharrisatcheckr
Copy link
Author

@sl0thentr0py Thanks for the tip about Sentry.close!

I don't think init should remove them.

Would you be able to say a little more here as to why? Sentry.init in my experience has the effect of resetting most other settings to defaults. As a developer user, I'd expect that to mean all defaults, including resetting global event processors, unless I'm misunderstanding the intent of .init.

Thanks for the attention here, all the same. 🙂

@st0012
Copy link
Collaborator

st0012 commented Nov 24, 2023

It looks like you're calling Sentry.init multiple times for testing? If that's the case, I recommend trying the test helper instead of manually resetting SDK related environments.

That said, the current test helper doesn't cover global processors either, which is something we should improve. Do you think there's anything else we can add to the test helper so you can utilise it in your tests?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants