[Dataset Quality] Fix tests for degraded fields flyout#202288
[Dataset Quality] Fix tests for degraded fields flyout#202288tonyghiani merged 3 commits intoelastic:mainfrom
Conversation
|
I think this is a good solution give we never know when these components are going to be available so increasing timeouts wouldn't work. |
Some tests also rely on changes on the UI components which might not be immediate, I would leave those retries as they are since I don't know which ones are fixing previous issues. If the element is already there, the retry won't wait for the whole time anyway. |
mohamedhamed-ahmed
left a comment
There was a problem hiding this comment.
Changes LGTM! Thank you 🚀
|
Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs) |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7537[✅] x-pack/test_serverless/functional/test_suites/observability/config.ts: 50/50 tests passed. |
💚 Build Succeeded
Metrics [docs]
History
|
|
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/12118005054 |
## 📓 Summary Closes elastic#198849 Closes elastic#200287 Closes elastic#201273 Closes elastic#201975 The above issues were raised with similar conditions which converged in the following assumptions: - They are raised due to timeout identifying a visual element on the degraded fields flyout. - They are raised due to a missing UI element, which is part of a common sub-tree conditionally rendered when the data analysis is completed. - They are raised in serverless tests, where the latency might be randomly higher. Given the nature of these tests, which locally always pass correctly given the fastest nature of a local setup, I assume these random failures are due to latency on the common request gating the rendering of these sections. As a fix, I added a wait on the global loading indicator before the assertions, which should wait for the data loading to be completed before running the assertions on the UI elements. Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co> (cherry picked from commit d13904e)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
#202432) # Backport This will backport the following commits from `main` to `8.x`: - [[Dataset Quality] Fix tests for degraded fields flyout (#202288)](#202288) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Marco Antonio Ghiani","email":"marcoantonio.ghiani01@gmail.com"},"sourceCommit":{"committedDate":"2024-12-02T11:04:48Z","message":"[Dataset Quality] Fix tests for degraded fields flyout (#202288)\n\n## 📓 Summary\r\n\r\nCloses #198849 \r\nCloses #200287 \r\nCloses #201273 \r\nCloses #201975 \r\n\r\nThe above issues were raised with similar conditions which converged in\r\nthe following assumptions:\r\n- They are raised due to timeout identifying a visual element on the\r\ndegraded fields flyout.\r\n- They are raised due to a missing UI element, which is part of a common\r\nsub-tree conditionally rendered when the data analysis is completed.\r\n- They are raised in serverless tests, where the latency might be\r\nrandomly higher.\r\n\r\nGiven the nature of these tests, which locally always pass correctly\r\ngiven the fastest nature of a local setup, I assume these random\r\nfailures are due to latency on the common request gating the rendering\r\nof these sections.\r\n\r\nAs a fix, I added a wait on the global loading indicator before the\r\nassertions, which should wait for the data loading to be completed\r\nbefore running the assertions on the UI elements.\r\n\r\nCo-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>","sha":"d13904eb6596edd51e4d52aa74c24c070be3ce5c","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","Team:obs-ux-logs"],"title":"[Dataset Quality] Fix tests for degraded fields flyout","number":202288,"url":"https://github.com/elastic/kibana/pull/202288","mergeCommit":{"message":"[Dataset Quality] Fix tests for degraded fields flyout (#202288)\n\n## 📓 Summary\r\n\r\nCloses #198849 \r\nCloses #200287 \r\nCloses #201273 \r\nCloses #201975 \r\n\r\nThe above issues were raised with similar conditions which converged in\r\nthe following assumptions:\r\n- They are raised due to timeout identifying a visual element on the\r\ndegraded fields flyout.\r\n- They are raised due to a missing UI element, which is part of a common\r\nsub-tree conditionally rendered when the data analysis is completed.\r\n- They are raised in serverless tests, where the latency might be\r\nrandomly higher.\r\n\r\nGiven the nature of these tests, which locally always pass correctly\r\ngiven the fastest nature of a local setup, I assume these random\r\nfailures are due to latency on the common request gating the rendering\r\nof these sections.\r\n\r\nAs a fix, I added a wait on the global loading indicator before the\r\nassertions, which should wait for the data loading to be completed\r\nbefore running the assertions on the UI elements.\r\n\r\nCo-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>","sha":"d13904eb6596edd51e4d52aa74c24c070be3ce5c"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/202288","number":202288,"mergeCommit":{"message":"[Dataset Quality] Fix tests for degraded fields flyout (#202288)\n\n## 📓 Summary\r\n\r\nCloses #198849 \r\nCloses #200287 \r\nCloses #201273 \r\nCloses #201975 \r\n\r\nThe above issues were raised with similar conditions which converged in\r\nthe following assumptions:\r\n- They are raised due to timeout identifying a visual element on the\r\ndegraded fields flyout.\r\n- They are raised due to a missing UI element, which is part of a common\r\nsub-tree conditionally rendered when the data analysis is completed.\r\n- They are raised in serverless tests, where the latency might be\r\nrandomly higher.\r\n\r\nGiven the nature of these tests, which locally always pass correctly\r\ngiven the fastest nature of a local setup, I assume these random\r\nfailures are due to latency on the common request gating the rendering\r\nof these sections.\r\n\r\nAs a fix, I added a wait on the global loading indicator before the\r\nassertions, which should wait for the data loading to be completed\r\nbefore running the assertions on the UI elements.\r\n\r\nCo-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>","sha":"d13904eb6596edd51e4d52aa74c24c070be3ce5c"}}]}] BACKPORT--> Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>
## 📓 Summary Closes elastic#198849 Closes elastic#200287 Closes elastic#201273 Closes elastic#201975 The above issues were raised with similar conditions which converged in the following assumptions: - They are raised due to timeout identifying a visual element on the degraded fields flyout. - They are raised due to a missing UI element, which is part of a common sub-tree conditionally rendered when the data analysis is completed. - They are raised in serverless tests, where the latency might be randomly higher. Given the nature of these tests, which locally always pass correctly given the fastest nature of a local setup, I assume these random failures are due to latency on the common request gating the rendering of these sections. As a fix, I added a wait on the global loading indicator before the assertions, which should wait for the data loading to be completed before running the assertions on the UI elements. Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
📓 Summary
Closes #198849
Closes #200287
Closes #201273
Closes #201975
The above issues were raised with similar conditions which converged in the following assumptions:
Given the nature of these tests, which locally always pass correctly given the fastest nature of a local setup, I assume these random failures are due to latency on the common request gating the rendering of these sections.
As a fix, I added a wait on the global loading indicator before the assertions, which should wait for the data loading to be completed before running the assertions on the UI elements.