# Backport
This will backport the following commits from `main` to `8.11`:
- [[Dashboard] Fix flaky `sync_colors.tsx` test
(#172633)](https://github.com/elastic/kibana/pull/172633)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Hannah
Mudge","email":"Heenawter@users.noreply.github.com"},"sourceCommit":{"committedDate":"2023-12-06T14:55:13Z","message":"[Dashboard]
Fix flaky `sync_colors.tsx` test (#172633)\n\n## Summary\r\n\r\nIt is
possible for the `noDataPopover` to take more than the
`100ms`\r\ntimeout from `ensureHiddenNoDataPopover` (pictured below) to
appear - in\r\nthese cases, any tests that make use of the Lens page
object's\r\n`goToTimeRange` method will fail due to clicking the wrong
element (the\r\ntour step rather than the time
picker).\r\n\r\n\r\n\r\n\r\n\r\nWhile
my initial thought was to simply increase the timeout for
the\r\n`noDataPopover` check, this isn't ideal - **a lot** of tests use
the\r\n`goToTimeRange` method and, by doing this, we would be slowing
down\r\n**every single one of them** even when the test wouldn't have
failed to\r\nbegin with! Instead, I've chosen to surround the important
parts of the\r\ncode in `goToTimeRange` with a `retry` - that way, if
the\r\n`noDataPopover` never shows up or it shows up comfortably within
the\r\n`100ms` timeout, the impact to the speed of a given test will
be\r\n**minimal**; however, if the no data popover shows up **outside**
of\r\nthis timeout, the retry will save the test from outright
failure.\r\n\r\n### [Flaky
Test\r\nRunner](1ac033d7-6cc1-4789-9a2b-6c7b8c34f67c)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"d9e2d06512196ff6800a8441fc4605c258f206dd","branchLabelMapping":{"^v8.12.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Presentation","loe:small","release_note:skip","impact:critical","backport:prev-minor","v8.12.0","v8.13.0"],"number":172633,"url":"https://github.com/elastic/kibana/pull/172633","mergeCommit":{"message":"[Dashboard]
Fix flaky `sync_colors.tsx` test (#172633)\n\n## Summary\r\n\r\nIt is
possible for the `noDataPopover` to take more than the
`100ms`\r\ntimeout from `ensureHiddenNoDataPopover` (pictured below) to
appear - in\r\nthese cases, any tests that make use of the Lens page
object's\r\n`goToTimeRange` method will fail due to clicking the wrong
element (the\r\ntour step rather than the time
picker).\r\n\r\n\r\n\r\n\r\n\r\nWhile
my initial thought was to simply increase the timeout for
the\r\n`noDataPopover` check, this isn't ideal - **a lot** of tests use
the\r\n`goToTimeRange` method and, by doing this, we would be slowing
down\r\n**every single one of them** even when the test wouldn't have
failed to\r\nbegin with! Instead, I've chosen to surround the important
parts of the\r\ncode in `goToTimeRange` with a `retry` - that way, if
the\r\n`noDataPopover` never shows up or it shows up comfortably within
the\r\n`100ms` timeout, the impact to the speed of a given test will
be\r\n**minimal**; however, if the no data popover shows up **outside**
of\r\nthis timeout, the retry will save the test from outright
failure.\r\n\r\n### [Flaky
Test\r\nRunner](1ac033d7-6cc1-4789-9a2b-6c7b8c34f67c)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"d9e2d06512196ff6800a8441fc4605c258f206dd"}},"sourceBranch":"main","suggestedTargetBranches":["8.13"],"targetPullRequestStates":[{"branch":"main","label":"v8.12.0","labelRegex":"^v8.12.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/172633","number":172633,"mergeCommit":{"message":"[Dashboard]
Fix flaky `sync_colors.tsx` test (#172633)\n\n## Summary\r\n\r\nIt is
possible for the `noDataPopover` to take more than the
`100ms`\r\ntimeout from `ensureHiddenNoDataPopover` (pictured below) to
appear - in\r\nthese cases, any tests that make use of the Lens page
object's\r\n`goToTimeRange` method will fail due to clicking the wrong
element (the\r\ntour step rather than the time
picker).\r\n\r\n\r\n\r\n\r\n\r\nWhile
my initial thought was to simply increase the timeout for
the\r\n`noDataPopover` check, this isn't ideal - **a lot** of tests use
the\r\n`goToTimeRange` method and, by doing this, we would be slowing
down\r\n**every single one of them** even when the test wouldn't have
failed to\r\nbegin with! Instead, I've chosen to surround the important
parts of the\r\ncode in `goToTimeRange` with a `retry` - that way, if
the\r\n`noDataPopover` never shows up or it shows up comfortably within
the\r\n`100ms` timeout, the impact to the speed of a given test will
be\r\n**minimal**; however, if the no data popover shows up **outside**
of\r\nthis timeout, the retry will save the test from outright
failure.\r\n\r\n### [Flaky
Test\r\nRunner](1ac033d7-6cc1-4789-9a2b-6c7b8c34f67c)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"d9e2d06512196ff6800a8441fc4605c258f206dd"}},{"branch":"8.13","label":"v8.13.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
385f33e9d4