ActiveSupport::Cache (or Rails) will use Rails.configuration.cache_store for "backend" value despite cache type

[zachmccormick]

 def finish_trace_cache(payload)
            # retrieve the tracing context and continue the trace
            tracing_context = payload.fetch(:tracing_context)
            span = tracing_context[:dd_cache_span]
            return unless span && !span.finished?
            begin
              # discard parameters from the cache_store configuration
              if defined?(::Rails)
                store, = *Array.wrap(::Rails.configuration.cache_store).flatten
                span.set_tag(Ext::TAG_CACHE_BACKEND, store)
              end
...

the ::Rails.configuration.cache_store bit ignores what store actually is and just sends up Rails' default configuration. This is detrimental to those of us that use multiple layers of caching (memory, same-machine memcached, same-zone memcached; for Braze's use case)

[ericmustin]

@zachmccormick Hey there, thanks for flagging this. We have some upcoming sprint work scheduled around improving our Rails Instrumentation and I think it would make sense to try to include this work in there. We'll try to update here with any relevant PRs when they're made.

[zachmccormick]

awesome - thank you!

[rahul342]

@delner @ericmustin any updates on this? We have similar issue where we used multiple stores, but everything gets tagged as our Rails.cache store. I checked this is the still the issue on latest 0.54.2

[marcotc]

@zachmccormick & @rahul342, I took at this and got a bit of work done to fix it: https://github.com/DataDog/dd-trace-rb/pull/2262

The issue can be solve by simply reporting the correct backend type for the ActiveSupport cache instance being instrumented.

There were a few hurdles in order to keep it backwards compatible, but it seems tenable.

I'll circle back when the changes are shipped in a public release.