Don't record duration for failing requests.
What does this MR do?
If a request failed, we shouldn't care how fast it failed.
These recordings are used for the apdex aspect for error budget recordings for stage groups. With the current implementation, if a stage group has a single request that failed fast, they would have 50% availability. This should be 0% to match how we measure availability for the services themselves.
For those, we only measure apdex if the request succeeded: https://gitlab.com/gitlab-org/gitlab/blob/d969d80acb4bb416d2b28423de6810d314a3cfc8/lib/gitlab/metrics/requests_rack_middleware.rb#L82
Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
I have included a changelog entry, or it's not needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Edited by Bob Van Landuyt