Update dependency newrelic_rpm to v10.9.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
newrelic_rpm (source, changelog)	10.4.0 → 10.9.1

---

Release Notes

newrelic/newrelic-ruby-agent (newrelic_rpm)

v10.9.1

Compare Source

• Bugfix: Action Controller instrumentation no longer errors when it can't identify the controller class

  When the agent could not identify a request's controller class, it logged TypeError: no implicit conversion of nil into String and then NoMethodError: undefined method 'finish' for nil, and recorded no data for that request. These transactions are now named Controller/(unknown)/<action> and recorded normally. PR#3691

• Bugfix: Prevent Parallel workers from hanging when reporting large payloads

  When parallel instrumentation was enabled, Parallel.each/Parallel.map with in_processes: could hang forever. Each worker inherited the pipe write ends the agent registered for its earlier siblings, so those pipes couldn't reach end-of-file, and the agent's pipe listener thread blocked waiting on one of them. Any worker whose data exceeded the operating system pipe buffer then blocked on exit. Now, the agent closes each pipe's write end in the parent right after forking, and the listener no longer blocks on a single pipe while others still have data waiting. Thank you to @​yayamochi for reporting this bug. Issue#3680 PR#3688

• Bugfix: gRPC calls no longer fail on requests from Synthetics monitors

  When a request from a Synthetics monitor made a gRPC call, the agent added X-NewRelic-Synthetics to the call's metadata. gRPC only allows lowercase metadata keys, so the call raised ArgumentError: 'X-NewRelic-Synthetics' is an invalid header key. The agent now sends the synthetics headers in lowercase. gRPC server transactions also now read the synthetics headers from incoming metadata, so a gRPC service called during a Synthetics check records its trace and Synthetics attributes. PR#3693

v10.9.0

Compare Source

• Feature: Continuous Profiling (preview)

  Continuous Profiling is a new feature which is not yet generally available for use. The agent-side component code is now present in the agent but to actually use it ahead of the General Availability release, you will need to contact your New Relic sales representative to join the preview early.

  Continuous Profiling repeatedly samples the Ruby call stacks of your running application and reports them to New Relic, so you can see which methods are consuming the most CPU time (or allocating the most objects) in production, without adding code to your app.

  To turn it on, add the stackprof and google-protobuf gems to your application's Gemfile, then set profiling.enabled to true:

    profiling.enabled: true

  With only profiling.enabled set, the agent samples CPU time every 10 milliseconds for the life of the process. These options let you tune that behavior:

  Configuration name	Default	Behavior
  profiling.enabled	false	If true, the agent collects and reports continuous profiling data.
  profiling.include	cpu	What to sample: cpu for CPU time, or object for object allocations.
  profiling.sample_period	0.01	Seconds between stack samples. Only used when profiling.include is cpu. Must be between 0.000001 and 0.999999.
  profiling.object_allocation_interval	10000	Object allocations between stack samples. Only used when profiling.include is object. Must be between 1000 and 999999.
  profiling.delay	0	Milliseconds to wait before profiling starts. 0 starts immediately.
  profiling.duration	0	Milliseconds to profile before stopping automatically. 0 profiles until the process exits.

  PR#3617

• Feature: Add support for Dalli 5.1.1

  Dalli 5.1.1 added arguments to some of the methods the agent instruments, which could raise an ArgumentError on multi-key operations or cause request options to be silently dropped. Now, the agent accepts and forwards a variable number of positional and keyword arguments for these methods. PR#3683

v10.8.0

Compare Source

• Feature: Report a unique hostname for Google Cloud Run Worker Pools and Jobs

  The Cloud Run hostname support added in PR#3609 detected Cloud Run by looking for K_REVISION, which Cloud Run Services set. The agent now also recognizes CLOUD_RUN_REVISION (Worker Pools) and CLOUD_RUN_EXECUTION (Jobs), so utilization.gcp_cloud_run.use_instance_as_host applies to all three resource types. When utilization.gcp_cloud_run.include_revision_in_host is true, the hostname uses whichever of those variables is set, for example {CLOUD_RUN_EXECUTION}-{instance id} on a Job. Issue#3651 Thanks to @​choznerol for contributing this enhancement! PR#3652

• Feature: Add browser_monitoring.version configuration option

  Customers can now pin the exact browser agent loader version New Relic injects by setting the new browser_monitoring.version configuration option. See the browser agent EOL policy for which versions are currently available and supported.

• Feature: Add span.kind to background job libraries

  Now, the span.kind attribute will be added to produce and consume operations from background job libraries. This includes ActiveJob, Sidekiq, Resque and DelayedJob. PR#3636

• Bugfix: DelayedJob instrumentation no longer reinstalls itself on every worker under prepend mode

  When DelayedJob instrumentation is installed via prepend (the default), creating more than one Delayed::Worker in the same process caused the agent to log "Installing DelayedJob instrumentation" and reinitialize the plugin again for each additional worker. This was harmless but noisy; it's now only done once per process, matching the existing chain-instrumentation behavior. PR#3654

• Bugfix: Allowlisted configuration values are no longer case sensitive

  Configuration options that validate against an allowlist now match values regardless of case. For example, setting slow_sql.record_sql to OBFUSCATED or ObFuScAtEd is now treated the same as obfuscated. Previously, a value with unexpected casing that wasn't an exact match would silently fall back to the default. PR#3645

• Bugfix: Puma instrumentation works when Puma is lazy-loaded

  With gem "puma", require: false, Puma was not yet loaded when the agent's dependency check ran, so Puma instrumentation would fail to install. The agent now recognizes Puma::RackHandler as evidence that Puma is present, fixing this issue. Thank you @​jdelStrother for finding this issue and providing a solution! PR#3650

v10.7.1

Compare Source

• Bugfix: Resolve ArgumentError on multi-key operations with Dalli 5.1.0

  This fix updates Dalli instrumentation to accept and forward optional request options arguments in multi and pipelined operations. Our thanks go to @​dbackeus for contributing a fix! PR#3642

• Bugfix: Async::HTTP requests no longer raise NoMethodError when a segment fails to start

  If the agent encountered an internal error while creating the segment for an Async::HTTP request, the instrumentation went on to use that missing segment and could raise a NoMethodError. This is now fixed, thanks to @​ydah. PR#3640

v10.7.0

Compare Source

• Feature: Add transaction_tracer.cap_segment_artifacts configuration option

  Long-running transactions with many segments can cause continuously increasing memory usage for the lifetime of the transaction. The agent now offers an opt-in transaction_tracer.cap_segment_artifacts configuration option (defaults to false). When enabled, once transaction_tracer.limit_segments is reached, the agent also stops recording exclusive time for any segments created afterward in that transaction, reducing memory usage at the cost of less accurate timing data for the transaction.PR#3615

• Feature: Add Puma server-statistics instrumentation

  The agent now samples Puma's cluster-wide server statistics and reports them as Ruby/Puma/* timeslice metrics, including backlog, running, pool_capacity, max_threads, and requests_count. Statistics are sampled in single mode and in clustered mode when preload_app! is enabled. This instrumentation is disabled by default; enable it by setting disable_puma_instrumentation to false. When enabled, the agent starts a reporting thread in the Puma master process to deliver these metrics, which runs an additional agent connection alongside the Puma workers. The sampling interval is configurable via the new puma.sample_rate setting (default 60 seconds). Requires Puma 6.6 or later. See our docs for more information.

  Thanks so much to @​ashleyboehs contributing this new feature. PR#3578

• Feature: Report a unique hostname for Google Cloud Run instances

  The agent now detects Cloud Run and reports the GCP instance id as the hostname so individual instances can be distinguished. Before this change, all Google Cloud Run hostnames were localhost. This feature is controlled by the new utilization.gcp_cloud_run.use_instance_as_host configuration option (default true). Set utilization.gcp_cloud_run.include_revision_in_host (default false) to true to report the hostname as {K_REVISION}-{instance id} instead, where K_REVISION is the Cloud Run revision name. Thank you to @​kawa-onushi for suggesting this improvement. Issue#3295 PR#3609

• Bugfix: Slow SQL no longer recorded after transaction_tracer.limit_segments exceeded

  Once a transaction exceeded transaction_tracer.limit_segments, datastore segments created afterward still could have their slow SQL recorded. The agent now stops recording slow SQL for any segment created after the limit is reached. PR#3615

• Bugfix: Explain plans could target the wrong database in multi-database Rails apps (Rails >= 7.2)

  On Rails 7.2+, the agent gathered explain plans using a connection from the app's default/shared pool rather than a dedicated one. This primarily affected multi-database apps. Explain plans could be generated against the wrong database, and a failed explain could leave a shared connection in a bad state, affecting unrelated requests. The agent now uses its own dedicated connection for explain plans, as it did before Rails 7.2, and resets or discards that connection whenever an explain attempt fails, so a bad connection is never reused. Thank you, @​masiafrest for the detailed report! Issue#3610 PR#3612

• Bugfix: Browser monitoring instrumentation no longer fails with FrozenError

  When a response body's first fragment was a frozen String and there were multiple fragments, browser instrumentation hit a FrozenError and the browser timing header was never injected. This began appearing with ERB 6.0.3+, which started freezing more of its compiled strings. This issue is now fixed. Thank you to @​md5 for reporting this issue! Issue#3624PR#3625

• Bugfix: Normalize boolean configuration values to allow all casing

  In version 9.x, the agent accepted capitalized boolean values, like "FALSE", and mixed-case values like "True". Version 10.0.0 included PR#3341, which unintentionally removed the case-insensitive requirement. This caused users who had any casing besides all lowercase to have their configuration options fall back to the defaults. Now, the agent uses case-insensitive checks again. Our thanks go to @​willie for bringing this to our attention. Issue#3632 PR#3633

v10.6.0

Compare Source

• Feature: SpanLink events are now supported for the Hybrid Agent

  Spans created by an OpenTelemetry API can now have Span Links associated with them. Links can be added on a span's start, by passing them to the links argument, or by calling the OpenTelemetry::Trace::Span#add_link API. PR#3586

• Feature: SpanEvent events are now supported for the Hybrid Agent

  Spans created by an OpenTelemetry API can now have SpanEvent events associated with them via the OpenTelemetry::Trace::Span#add_event API. SpanEvent events capture timestamped annotations on a span and are sent to New Relic alongside the parent span. PR#3587

• Feature: Set Span Kind on all Hybrid Agent spans

  Previously, only OpenTelemetry spans translated into external request segments or datastore segments added span kind as an attribute. Now, the agent adds span kind to all OpenTelemetry spans where the value is available. PR#3589

• Feature: Add support for OpenTelemetry::Tracer#start_root_span

  The OpenTelemetry::Tracer#start_root_span API can now be used to force a transaction to start for a given span, provided it has a :server or :consumer span kind. For any other span kinds, it will no-op. This method is most commonly used in background job instrumentation. PR#3588

• Bugfix: Fix instrumentation.rails_event_logger: false not disabling the instrumentation

  Setting instrumentation.rails_event_logger to false was not disabling the Rails.event instrumentation as expected. The instrumentation would still be installed during Rails boot. This has been fixed. PR#3564

• Bugfix: Normalize boolean-like values to disabled for instrumentation config keys

  Setting any instrumentation.* config key to false, no, or off instead of disabled will now resolve to disabled and prevent the instrumentation from being installed. PR#3579

• Bugfix: Per-library logging supportability metrics now reflect each library's instrumentation state

  The Supportability/Logging/Ruby/{library}/{enabled|disabled} metrics previously echoed application_logging.enabled for every library, so disabling a single logging instrumentation or running without one of its gems still reported enabled. Each library now reports based on its own instrumentation state. PR#3571

v10.5.0

Compare Source

• Feature: Add Dalli 5.0 support and fix meta protocol instrumentation

  The agent now supports Dalli 5.0+, which removed Dalli::Protocol::Binary in favor of the meta protocol exclusively. For Dalli 3.2.0+, pipelined_get instrumentation now correctly targets Dalli::Protocol::Base (where the method is defined) rather than Dalli::Protocol::Binary, fixing a gap where get_multi calls went uninstrumented when using the meta protocol. For Dalli 5.0+, the agent additionally instruments Dalli::Protocol::Meta#read_multi_req, which is invoked by Dalli's single-server get_multi optimization. PR#3541

• Feature: Add active_record_use_table_name configuration option

  A new configuration option, active_record_use_table_name, uses an Active Record model's table name instead of its class name when naming metrics, spans, and transaction trace segments. This can particularly be helpful to reduce cardinality in applications using single-table inheritance. The option defaults to false to preserve existing behavior. PR#3540

• Feature: Partially redact license keys in agent logs

  Previously, the agent would fully redact New Relic license keys in agent logs. Now, the first 10 characters are visible while the rest are replaced with *. This preserves enough to troubleshoot region-related issues without exposing the secret portion of the key. PR#3547

• Bugfix: Fix Semantic Logger instrumentation incompatibility with rails_semantic_logger

  Previously, an ArgumentError would be raised when an exception reached ActionDispatch::DebugExceptions while using rails_semantic_logger. This has been fixed. Thank you to @​jdelStrother for reporting this! PR#3548

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.