Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RUM-4894 Fix the CoreTracer flaky tests #2081

Merged
merged 1 commit into from
Jun 13, 2024

Conversation

mariusc83
Copy link
Member

What does this PR do?

A brief description of the change being made with this pull request.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@mariusc83 mariusc83 self-assigned this Jun 12, 2024
@mariusc83 mariusc83 requested review from a team as code owners June 12, 2024 14:26
@@ -803,7 +803,7 @@ internal class OtelTracerProviderTest {
val keptSpans = spansWritten.filter {
it.getInt(SAMPLING_PRIORITY_KEY) == PrioritySampling.USER_KEEP.toInt()
}
val offset = 10
val offset = 20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the test will be still flaky, even with this change. And 20% is quite big offset, maybe it makes sense only a small absolute values. And if you have actual say 1, and expected as 2, this won't help (because diff will be 50% for such numbers).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested with 1000 repeated tests and never failed. I think it is fine but also my question is regarding the offset as it is too high. Should we still keep this test ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a definitive answer here. I think we have similar tests checking sampling rate in other modules, and they probably don't have a high offset? Maybe we can modify the test somehow?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes...will try to have a look what else I can do

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

One way to limit flakyness is to increase the numberOfSpans

@mariusc83 mariusc83 requested a review from 0xnm June 12, 2024 14:53
@codecov-commenter
Copy link

codecov-commenter commented Jun 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.58%. Comparing base (5197289) to head (dc254f2).
Report is 2 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #2081      +/-   ##
===========================================
- Coverage    68.73%   68.58%   -0.15%     
===========================================
  Files          719      719              
  Lines        26571    26569       -2     
  Branches      4472     4472              
===========================================
- Hits         18262    18220      -42     
- Misses        7123     7139      +16     
- Partials      1186     1210      +24     

see 22 files with indirect coverage changes

@mariusc83 mariusc83 force-pushed the mconstantin/rum-4894/fix-coretracer-flaky-tests branch 2 times, most recently from 8f5f6b1 to 7ee5529 Compare June 13, 2024 07:17
fun `M use user-keep or user-drop priority W buildSpan { tracer was provided a sample rate }`(
@StringForgery fakeInstrumentationName: String,
@DoubleForgery(min = 0.0, max = 100.0) sampleRate: Double,
@IntForgery(min = 0, max = 100) sampleRate: Int,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

Why do we need to generate an Int and cast it to a Double instead of generating a Double directly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes good catch was a left over during my tests to see why it is flaky

val offset = 10
// Because of the way sampling works the deviation can be quite high so we will have to use an offset of 20
// here to make sure this test will never be flaky
val offset = 20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

The offset should be based off of the numberOfSpans and not hardcoded, e.g.:

    val offset = (numberOfSpans * 15) / 100

@@ -803,7 +803,7 @@ internal class OtelTracerProviderTest {
val keptSpans = spansWritten.filter {
it.getInt(SAMPLING_PRIORITY_KEY) == PrioritySampling.USER_KEEP.toInt()
}
val offset = 10
val offset = 20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

One way to limit flakyness is to increase the numberOfSpans

@mariusc83 mariusc83 force-pushed the mconstantin/rum-4894/fix-coretracer-flaky-tests branch from 7ee5529 to 4c94c57 Compare June 13, 2024 08:34
@mariusc83 mariusc83 requested review from xgouchet and 0xnm June 13, 2024 08:46
val span = tracer.spanBuilder(forge.anAlphabeticalString()).startSpan()
// there is a throttle on the sampler which drops all the spans over the 100 limit in 1 second
// so we need to sleep a bit to make sure the spans are not dropped because of throttling
Thread.sleep(100)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this makes test very slow: 100ms*300 spans is 30 seconds at least for waiting in this test, which is a lot.

drops all the spans over the 100 limit in 1 second

it means we can sleep for 10ms instead of 100 to be within the limit? But ideally we should disable throttling for the test or change the threshold.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes I wanted to make sure but indeed we can sleep for 10ms

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still ideally we won't have to use sleep, but 3s is much better than 30s.

@mariusc83 mariusc83 force-pushed the mconstantin/rum-4894/fix-coretracer-flaky-tests branch from 4c94c57 to dc254f2 Compare June 13, 2024 11:54
@mariusc83 mariusc83 requested a review from 0xnm June 13, 2024 11:54
val offset = 10
// Because of the way sampling works the deviation can be quite high so we will have to use an offset of 15%
// here to make sure this test will never be flaky
val offset = numberOfSpans * 15 / 100
Copy link
Member

@0xnm 0xnm Jun 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I think here we should use float types, otherwise we are losing a lot by doing an integer division.

Suggested change
val offset = numberOfSpans * 15 / 100
val offset = numberOfSpans * 15f / 100

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the offset needs to be an int in the end so I will keep it like that.

@mariusc83 mariusc83 merged commit 98c43e2 into develop Jun 13, 2024
20 checks passed
@mariusc83 mariusc83 deleted the mconstantin/rum-4894/fix-coretracer-flaky-tests branch June 13, 2024 13:24
@xgouchet xgouchet added this to the 2.11.x milestone Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants