bugfix: expected HTTP codes / error classes / error messages shouldn't impact Apdex #2619
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If an error is either expected (which still creates an entry in the Errors Inbox) or ignored (which does not), the transaction's Apdex should not factor in the error. A bug was discovered involving errors that were expected by way of their HTTP response codes that would cause those errors to impact Apdex. Errors that were expected via the agent's Noticed Errors API would correctly not impact Apdex, but HTTP response code based expected errors would incorrectly do so. Now ignored errors and both kinds of expected errors will correctly not impact Apdex when observed during a transaction. resolves #2594
fallwith
requested review from
hannahramadan,
kaylareopelle and
tannalynn
as code owners
changelog entry for the HTTP status code expected errors Apdex impact bugfix
fallwith
commented
May 2, 2024
| @@ -228,7 +228,9 @@ def assert_metrics_recorded(expected) | |||
| expected.each do |specish, expected_attrs| | |||
| expected_spec = metric_spec_from_specish(specish) | |||
| actual_stats = NewRelic::Agent.instance.stats_engine.to_h[expected_spec] | |||
| if !actual_stats | |||
| if actual_stats | |||
| assert(actual_stats) | |||
There was a problem hiding this comment.
Previously if assert_metrics_recorded was called to simply check that the metric itself was recorded and no expected attributes were specified, no Minitest assertions would actually be performed. Now an assert will be called.
florianpilz
approved these changes
May 2, 2024
update the changelog and source comments to explain that by looping in `ErrorCollector#expected?` (which calls `ErrorFilter#expected?`), we're actually fixing broken expected-errors-should-not-impact-apdex behavior for all 3 "expected" configuration parameter lists: HTTP status codes, classes, and errors
These lines were supposed to be removed as part of acb8297
fallwith
changed the title
SimpleCov Report
|
"corresponding" Co-authored-by: Kayla Reopelle (she/her) <87386821+kaylareopelle@users.noreply.github.com>
Improve formatting of the expected errors Apdex impact bugfix entry Co-authored-by: Kayla Reopelle (she/her) <87386821+kaylareopelle@users.noreply.github.com>
Improve the expected errors Apdex impact bugfix entry's description Co-authored-by: Kayla Reopelle (she/her) <87386821+kaylareopelle@users.noreply.github.com>
"user defined" -> "user-defined" Co-authored-by: Kayla Reopelle (she/her) <87386821+kaylareopelle@users.noreply.github.com>
tannalynn
reviewed
May 2, 2024
Improve scope in expected error apdex bugfix entry Co-authored-by: Tanna McClure <tmcclure@newrelic.com>
tannalynn
approved these changes
May 3, 2024
kaylareopelle
approved these changes
May 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If an error is either expected (which still creates an entry in the Errors Inbox) or ignored (which does not), the transaction's Apdex should not factor in the error.
A bug was discovered involving errors that were expected by way of their HTTP response codes that would cause those errors to impact Apdex. Errors that were expected via the agent's Noticed Errors API would correctly not impact Apdex, but HTTP response code based expected errors would incorrectly do so.
Now ignored errors and both kinds of expected errors will correctly not impact Apdex when observed during a transaction.
UPDATE: NOTE: the key change introduced here is that we no longer simply check a New Relic error object for an
expected: trueattribute value, but that we also perform anErrorCollector#expected?check. The attribute value can only be set by invoking thenotice_errorAPI, but the#expected?check will examine other things including the HTTP status code (if present), the customer defined expected error class list, and the customer defined expected error message list. So now all ways of configuring the agent to expect an error should result in any matching errors no longer having any impact on Apdex.resolves #2594