-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Resolver] Fix flaky test #80576
[Resolver] Fix flaky test #80576
Conversation
Under stress, this test would fail to finish in 5 seconds. With this new implementation it has better performance.
/** | ||
* An `enzyme` supported CSS selector for process node elements. | ||
*/ | ||
public static nodeElementSelector({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a module level function before. Adding it as a static field allows simulator tests to access it. This way they can use find
on returned enzyme
wrappers to find graph node elements.
/** | ||
* Given a `role`, return DOM nodes that have it. Use this to assert that ARIA roles are present as expected. | ||
*/ | ||
public domNodesWithRole(role: string): ReactWrapper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to test our ARIA compliance we need to select nodes by their role
attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will be useful - thanks.
💚 Build SucceededMetrics [docs]
To update your PR or re-run it, just comment with: |
Under stress, this test would fail to finish in 5 seconds. With this new implementation it has better performance.
* master: (102 commits) [Resolver] Fix flaky test (elastic#80576) Update Security Solution Bug Report Template (elastic#80668) [Observability] Kibana home page Observability link pointing to `/landing` (elastic#80636) [APM] Update User Experience app callout code to reflect new name (elastic#80641) [APM] Add missing ML privileges (elastic#80553) [DOCS] Adds intro line to the ML plugin readme file (elastic#80631) [ML] Functional tests - fix and re-enable validation API tests (elastic#80617) remove non-existing dependency from uptime plugin (elastic#80623) [ML] Fix job selection flyout overflow (elastic#80621) Move dashboard code in codeowner files to canvas team (elastic#80345) [Security Solution][Detections] Update signals template if outdated and rollover indices (elastic#80019) Sort service list by TPM if health is not shown (elastic#80447) Add in cluster version for sec telemetry sender. (elastic#80545) [Usage Collection] Usage collection add saved objects client to collector fetch context (elastic#80554) Change tag from experimental to beta (elastic#80443) [Metrics UI] Inventory view cleanup (elastic#79881) [Security Solutions][Detection Engine] Critical bug where value lists were not operational (elastic#80368) [Security Solution] Fix networkTopNFlow search strategy response (elastic#80362) [build] Retry docker pull (elastic#80432) add template for Security Solution bugs (elastic#80574) ...
Under stress, this test would fail to finish in 5 seconds. With this new
implementation it has better performance.
I also exposed a new static method on the
Simulator
class that creates CSS selectors for Resolver nodes and a new public method that selects DOM nodes via therole
attribute.Context
@XavierM noticed that this test occasionally failed on his local development environment. I was able to reproduce the issue by running the program
stress
:I verified that my CPU was under intense load using

htop
. Here is a partial screenshot. The bar charts 1 through 12 represent the CPU load of each of my computer's cores. "Load average" indicates how many of my cores my machine would have to have in order to complete all scheduled tasks concurrently (or something like that.)I then ran the

resolver
jest test suite via the CLI and saw that the test in question failed:Depending on your environment, you may need to use a higher number in the command:
stress -c 32
. Originally32
worked for me, but at a later time I needed to use 65. It will depend on the other programs running on your machine.Once I reliably reproduced the test failure, I switched out the implementation. My assumption was that the call to
closest
was not very performant. The original implementation worked by searching a DOM tree for 3 nodes using a CSS selector and then searching those node's ancestors using another CSS selector. The new implementation searched for the ancestors first, then their descendants.I re-ran the tests with the same load. The test in question now passed.
The pattern of using
stress
to include CPU load andhtop
to confirm that the load is high was useful in reproducing this flaky performance related issue.Checklist
Delete any items that are not applicable to this PR.
For maintainers