newrelic_rpm 9.2.1 → 9.2.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 24d17293feea3a15b482164d50f81a2f90a5540f25fee4d90e8472c1eb9d2f14
-  data.tar.gz: f8a2475b3a782c509dd417a7174b3067da223bc834236c97a99456bb96660ecc
+  metadata.gz: fd188401ae5aad975a09ff40578156c88aac17e12320f41ce4bee8149c769aaf
+  data.tar.gz: e32201ee58712dd1520f03ae23a46bd1c804c2991b835151a68643c00cf140e3
 SHA512:
-  metadata.gz: 6b2673019061b94d7800b6025ab88c9f6f096322f1309f3fac2d08c999731574f76997782b603327c4e2cb8ced6b45bfb02e47c2086f575dffe839607a8c92de
-  data.tar.gz: 7f7d7e8f5982346f59d22a19bfdabacbbf5a57fd907cc694078534ff45e1cadeaee8631d2a110a64e06874f94258cf0050c15534a9d5482f13fe295005fb22e9
+  metadata.gz: cf9190f9bece2103511dc53071120f3dc758dba82cf042c1892d3376dc73a7b66e8898908bfe8406d85ba49ad67f7c6f5b2826e8e9b2a07d29ea05f5a99b701c
+  data.tar.gz: 5a240785708c245119750b33df64e5467e7f9b8abf9daae8b568a452da1913f40862788323232928ecc6da489fc7b998118f2397293a55e4d371e3f0a1ae0ad5

data/CHANGELOG.md

@@ -1,5 +1,13 @@
 # New Relic Ruby Agent Release Notes
 
+## v9.2.2
+
+  Version 9.2.2 of the agent fixes a bug with the `Transaction#finished?` method.
+
+- **Bugfix: Transaction#finished? no longer throws a NoMethodError when initial_segment is nil**
+
+  This change adds a safe navigation operator to `Transaction#finished?` to prevent `NoMethodErrors` when a transaction does not have any segments. Our thanks goes to [@JulienDefrance](https://github.com/JulienDefrance) for reporting this issue. [PR#1983](https://github.com/newrelic/newrelic-ruby-agent/pull/1983)
+
 ## v9.2.1
 
   Version 9.2.1 fixes a bug causing the agent to continue storing data on finished transactions, and a bug preventing errors from being expected.
@@ -21,8 +29,8 @@
 
 - **Feature: Enhance performance for handling high numbers of nested actions**
 
-  With [Issue#1910](https://github.com/newrelic/newrelic-ruby-agent/issues/1910) community members [@parkerfinch](https://github.com/parkerfinch) and [@travisbell](https://github.com/travisbell) informed us of some CPU spikes and process hangs seen only when using the agent's thread instrumentation, which was enabled by default with v9.0. When thread instrumentation is enabled, instrumented actions taking place within threads are seen and reported on by the agent whereas they would have previously gone unnoticed. This is a great improvement to the agent's usefulness in an async context, and also makes it easier for higher numbers of nested actions to be observed. 
-  For example, if an instrumented background job framework (Sidekiq, Resque) kicks off a job that the agent notices and then that job in turn performs actions such as database queries that the agent also instruments, nested actions are seen. However, with very high (10,000+) numbers of actions nested within a single instrumented outer action, the agent would struggle to efficiently crunch through all of the collected data at the time when the outer action finished. 
+  With [Issue#1910](https://github.com/newrelic/newrelic-ruby-agent/issues/1910) community members [@parkerfinch](https://github.com/parkerfinch) and [@travisbell](https://github.com/travisbell) informed us of some CPU spikes and process hangs seen only when using the agent's thread instrumentation, which was enabled by default with v9.0. When thread instrumentation is enabled, instrumented actions taking place within threads are seen and reported on by the agent whereas they would have previously gone unnoticed. This is a great improvement to the agent's usefulness in an async context, and also makes it easier for higher numbers of nested actions to be observed.
+  For example, if an instrumented background job framework (Sidekiq, Resque) kicks off a job that the agent notices and then that job in turn performs actions such as database queries that the agent also instruments, nested actions are seen. However, with very high (10,000+) numbers of actions nested within a single instrumented outer action, the agent would struggle to efficiently crunch through all of the collected data at the time when the outer action finished.
   The agent should now be much more efficient when any observed action with lots of nested actions is finished. Our performance testing was conducted with hundreds of thousands of nested actions taking place, and we hope that the benefits of thread tracing can now be enjoyed without any drawbacks. Thanks very much [@parkerfinch](https://github.com/parkerfinch) and [@travisbell](https://github.com/travisbell)! [PR#1927](https://github.com/newrelic/newrelic-ruby-agent/pull/1927)
 
 - **Feature: The agent configuration will now reflect whether module prepending or method chaining was used for instrumentation**

data/lib/new_relic/agent/transaction.rb

@@ -440,7 +440,7 @@ module NewRelic
       end
 
       def finished?
-        initial_segment.finished?
+        initial_segment&.finished?
       end
 
       def create_initial_segment(options = {})

data/lib/new_relic/version.rb

@@ -7,7 +7,7 @@ module NewRelic
   module VERSION # :nodoc:
     MAJOR = 9
     MINOR = 2
-    TINY = 1
+    TINY = 2
 
     STRING = "#{MAJOR}.#{MINOR}.#{TINY}"
   end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: newrelic_rpm
 version: !ruby/object:Gem::Version
-  version: 9.2.1
+  version: 9.2.2
 platform: ruby
 authors:
 - Tanna McClure