Instrumentation configuration values not being properly preserved

[fallwith]

Updated 2024-10-11 As per Tanna's commented note below, this issue seems be related to an existing chain or prepend configuration setting being changed to unsatisfied incorrectly. This can convey incorrect information to the csec agent about what the APM agent did with a given instrumentation, but it does not impact regular APM usage of the instrumentation.

At this time it is hypothesized that only Padrino and the two forms of Dalli instrumentation are impacted.

The agent has offered support for module chaining based instrumentation installation dating back to a time before Ruby itself supported module prepending. Support for chaining has been retained primarily as a means to avoid colliding with other software that may itself be using module prepending.

Unfortunately it has been reported (internally) that agent's chain functionality is currently unreachable due to an apparent bug in the processing of the related configuration options.

Setting instrumentation.<library>: chain in the config file will see the agent not respect the chain value and use prepend instead.

developer notes: the issue seems to stem from DependencyDetection's use_prepend? method making calls to prepend_configured? - a method that does not exist.

[workato-integration]

https://new-relic.atlassian.net/browse/NR-322973

[tannalynn]

After looking into this a bit, the scope is different than initially reported to us. Chain instrumentation configuration is being used and installed just fine.

The prepend_configured? method is dynamically defined by the code here https://github.com/newrelic/newrelic-ruby-agent/blob/dev/lib/new_relic/dependency_detection.rb#L169 and there are no issues with the way it's being called.

The primary problem reported seems to actually be that

On passing instrumentation.sinatra: chain in newrelic.yml, config value is set as : :"instrumentation.sinatra"=>:unsatisfied"

I tested this with roda and found that when using this config as chain, chain is initially correctly used and installed, and that later after the agent is no longer using these values, there is some issue related to preserving the values of the configuration originally used by the agent.
This isn't behavior that was originally part of the ruby agent, and was instead introduced to support the security agent, so it seems there may be a bug related to that newer code.