Oleg Pudeyev

I do not work on tracing part of the library and could be wrong, but perhaps the issue is that https://github.com/DataDog/dd-trace-rb/blob/master/lib/datadog/tracing/contrib/karafka/monitor.rb#L21 uses the block form of `trace` which I assume...

``` gem 'datadog', '~> 2.0', require: 'datadog/auto_instrument' ``` This requests `datadog` to instrument everything it knows how to instrument which includes karafka. If you do not wish to instrument everything...

@mensfeld What about storing the span created in https://github.com/karafka/karafka/blob/master/lib/karafka/instrumentation/vendors/datadog/logger_listener.rb#L51 in thread/fiber-local storage so that it can be finished later? Would that work?

OK, is there any way to not have steep errors in these cases of valid Ruby code?

OK, I changed the type definition to: ``` class Base def self.foo: () -> untyped end module Mod def self.augment: (singleton(Base) base) -> untyped end ``` But steep thinks that...

I thought I did but I guess without `branch: 'master'`, `github: 'soutaro/steep'` does not request master branch? I checked again and the issue is half fixed. IF I declare the...

@katiekeel I created a new rails 7.1 application and I am not getting these messages with dd-trace-rb 2.12.2. Can you try that?

I reproduced with console1984 following the setup instructions at https://github.com/basecamp/console1984/tree/02b1b9ee7fd7050174b6a98c2b43057553621dc4 + setting CONSOLE_USER: ``` CONSOLE_USER=x be rails c -e production I, [2025-04-09T12:36:32.029041 #659] INFO -- datadog: [datadog] DATADOG CONFIGURATION -...

Stack trace: ``` ["/home/w/.cache/vendor/bundle/ruby/3.3.0/gems/console1984-0.2.2/lib/console1984/freezeable.rb:42:in `block in prevent_sensitive_method'", "/home/w/apps/dd-trace-rb/lib/datadog/tracing/contrib/active_record/utils.rb:53:in `connection_config'", "/home/w/apps/dd-trace-rb/lib/datadog/tracing/contrib/active_record/events/sql.rb:34:in `on_start'", "/home/w/apps/dd-trace-rb/lib/datadog/tracing/contrib/active_support/notifications/subscription.rb:125:in `call'", "/home/w/apps/dd-trace-rb/lib/datadog/tracing/contrib/active_support/notifications/subscription.rb:125:in `run'", "/home/w/apps/dd-trace-rb/lib/datadog/tracing/contrib/active_support/notifications/subscription.rb:90:in `start_span'", "/home/w/apps/dd-trace-rb/lib/datadog/tracing/contrib/active_support/notifications/subscription.rb:34:in `start'", "/home/w/.cache/vendor/bundle/ruby/3.3.0/gems/activesupport-7.1.5.1/lib/active_support/notifications/fanout.rb:159:in `block in start'", "/home/w/.cache/vendor/bundle/ruby/3.3.0/gems/activesupport-7.1.5.1/lib/active_support/notifications/fanout.rb:26:in `block in iterate_guarding_exceptions'", "/home/w/.cache/vendor/bundle/ruby/3.3.0/gems/activesupport-7.1.5.1/lib/active_support/notifications/fanout.rb:25:in `each'", "/home/w/.cache/vendor/bundle/ruby/3.3.0/gems/activesupport-7.1.5.1/lib/active_support/notifications/fanout.rb:25:in...

The offending call is this: https://github.com/DataDog/dd-trace-rb/blob/master/lib/datadog/tracing/contrib/active_record/utils.rb#L52-L53 It retrieves AR adapter configuration. Patch to dd-trace-rb to make the complaint go away: ``` --- a/lib/datadog/tracing/contrib/active_record/utils.rb +++ b/lib/datadog/tracing/contrib/active_record/utils.rb @@ -49,11 +49,14 @@ module...