Fix RumActionScopeTest tests failing under high CPU load#3604
Conversation
e165b77 to
e6cad7a
Compare
* Events created in RumActionScopeTest were using the real time so they were failing under high CPU * Also fix the missing resource key test setup not making sense since the key.toString for the resource key had no relation to the key so the null-ing was irrelevant and the assert statement at the end impossible to fail
e6cad7a to
cc2789d
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #3604 +/- ##
===========================================
- Coverage 72.85% 72.81% -0.04%
===========================================
Files 975 975
Lines 35277 35263 -14
Branches 5972 5974 +2
===========================================
- Hits 25700 25676 -24
- Misses 7915 7923 +8
- Partials 1662 1664 +2 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cc2789d372
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| System.gc() | ||
| assertThat(keyRef.get()) | ||
| .describedAs("resource key should have been garbage collected by now") | ||
| .isNull() |
There was a problem hiding this comment.
Avoid relying on a single GC cycle
On JVMs/CI configurations where System.gc() is ignored, disabled, or collection is simply delayed, this new assertion can fail even though RumActionScope only retains a weak reference to the key. That makes this unit test flaky before it reaches the behavior it is trying to verify; use a deterministic helper/retry loop or avoid asserting immediate collection after one GC request.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Current code is what was there before and wasn't the cause of flake, new assert will also better force us to see if the test behavior will fail since our test relies on the weak reference to get cleared to indicate the test scenario is valid.
If we see the asserts fail, we can do a gc loop
|
Just some thoughts: not directly related to this PR, but I would say, we need to get rid of the default value in
And pass that value to the constructor using |
@hamorillo good point! In one of my first, onboarding tasks: #3011 |
Agree, I remember taking a look at that; would require some work for sure. |
What does this PR do?
Motivation
local_ci.sh kept failing locally due to high CPU load
Failure: