[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls #179485
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Heenawter
added
release_note:fix
Team:Presentation
|
/ci |
|
/ci |
|
/ci |
Heenawter
force-pushed
the
fix-controls-drilldown-bug_2024-03-26
branch
from
54b01b5
to
dce759a
Compare
|
/ci |
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @Heenawter |
ThomThomson
approved these changes
Apr 2, 2024
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
Heenawter
added a commit
to Heenawter/kibana
that referenced
this pull request
Apr 2, 2024
…has no controls (elastic#179485) Closes elastic#179391 ## Summary We were previously only calling `setSavedState` for the control group on dashboard navigation **when the control group was defined in the loaded dashboard** - however, if either the source or destination dashboard had zero controls, this caused problems on navigation: - If the source dashboard had at least one control and the destination dashboard had zero, the destination dashboard's control group `lastSavedInput` would **not** get set in `navigateToDashboard` since it is undefined - i.e. the `lastSavedInput` on the destination dashboard's control group would **still be equal to** the `lastSavedInput` of the source dashboard's control group after navigation. Therefore, hitting "reset" would replace the destination dashboard's empty control group with the source's control group. - If the source dashboard had zero controls and the destination dashboard had at least one, the first step in navigation would work as expected - the `lastSavedInput` of the destination dashboard would be set appropriately. However, upon hitting the browser back button and triggering `navigateToDashboard` a second time, the source dashboard's control group's `lastSavedInput` would **not** get set properly (since it is undefined) and would therefore still be equal to the `lastSavedInput` of the destination dashboard. Therefore, hitting "reset" would replace the source's empty control group with the destination dashboard's controls. This fixes the above scenarios by calling `setSavedState` on the control group **even if** the last saved control group state is undefined. ### Race Condition Fix In my testing for this, I discovered **another** bug caused by a race condition where, on dashboard navigation, the subscription to the control group's `initialize$` subject was firing with the **wrong** input, so the `lastSavedFilters` would be calculated incorrectly. This caused the dashboard to get stuck in an unsaved changes state, like so: https://github.com/elastic/kibana/assets/8698078/14c553a9-21b3-40d0-96ac-0282e9e66911 I fixed this by removing this subscription (it was messy anyway 🙈) and replaced this logic with individual calls to `calculateFiltersFromSelections` - this should be easier to follow, and we ensure that we are **always** doing this calculation with the expected input. Since we aren't `awaiting` these calculations, it also shouldn't slow down the control group's initialization (which was the original reason for using a subscription). ### Checklist - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) - [x] Flaky test runner - https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5583 <br/>  ### For maintainers - [ ] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) (cherry picked from commit 507f09d) # Conflicts: # src/plugins/controls/public/control_group/embeddable/control_group_container.tsx
Heenawter
added a commit
that referenced
this pull request
Apr 2, 2024
…hboard has no controls (#179485) (#179842) # Backport This will backport the following commits from `main` to `8.13`: - [[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)](#179485) **Note:** This only fixes the "no controls" bug - the race condition also fixed in that PR does not need to be backported, since the code that caused it was not merged in 8.13. <!--- Backport version: 8.9.8 --> ### 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":"2024-04-02T14:10:53Z","message":"[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)\n\nCloses #179391 Summary\r\n\r\nWe were previously only calling `setSavedState` for the control group on\r\ndashboard navigation **when the control group was defined in the loaded\r\ndashboard** - however, if either the source or destination dashboard had\r\nzero controls, this caused problems on navigation:\r\n- If the source dashboard had at least one control and the destination\r\ndashboard had zero, the destination dashboard's control group\r\n`lastSavedInput` would **not** get set in `navigateToDashboard` since it\r\nis undefined - i.e. the `lastSavedInput` on the destination dashboard's\r\ncontrol group would **still be equal to** the `lastSavedInput` of the\r\nsource dashboard's control group after navigation. Therefore, hitting\r\n\"reset\" would replace the destination dashboard's empty control group\r\nwith the source's control group.\r\n- If the source dashboard had zero controls and the destination\r\ndashboard had at least one, the first step in navigation would work as\r\nexpected - the `lastSavedInput` of the destination dashboard would be\r\nset appropriately. However, upon hitting the browser back button and\r\ntriggering `navigateToDashboard` a second time, the source dashboard's\r\ncontrol group's `lastSavedInput` would **not** get set properly (since\r\nit is undefined) and would therefore still be equal to the\r\n`lastSavedInput` of the destination dashboard. Therefore, hitting\r\n\"reset\" would replace the source's empty control group with the\r\ndestination dashboard's controls.\r\n\r\nThis fixes the above scenarios by calling `setSavedState` on the control\r\ngroup **even if** the last saved control group state is undefined.\r\n\r\n### Race Condition Fix\r\n\r\nIn my testing for this, I discovered **another** bug caused by a race\r\ncondition where, on dashboard navigation, the subscription to the\r\ncontrol group's `initialize# Backport This will backport the following commits from `main` to `8.13`: - [[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)](#179485) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT subject was firing with the **wrong**\r\ninput, so the `lastSavedFilters` would be calculated incorrectly. This\r\ncaused the dashboard to get stuck in an unsaved changes state, like so:\r\n\r\n\r\n\r\nhttps://github.com/elastic/kibana/assets/8698078/14c553a9-21b3-40d0-96ac-0282e9e66911\r\n\r\n\r\n\r\nI fixed this by removing this subscription (it was messy anyway 🙈) and\r\nreplaced this logic with individual calls to\r\n`calculateFiltersFromSelections` - this should be easier to follow, and\r\nwe ensure that we are **always** doing this calculation with the\r\nexpected input. Since we aren't `awaiting` these calculations, it also\r\nshouldn't slow down the control group's initialization (which was the\r\noriginal reason for using a subscription).\r\n\r\n\r\n### Checklist\r\n\r\n\r\n- [x] This was checked for [cross-browser\r\ncompatibility](https://www.elastic.co/support/matrix#matrix_browsers)\r\n- [x] Flaky test runner -\r\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5583\r\n<br/>\r\n\r\n\r\n\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":"507f09d0b69a99f03f0c0cb19f10f1ea8584cd47","branchLabelMapping":{"^v8.14.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Presentation","loe:small","impact:high","backport:prev-minor","v8.14.0"],"number":179485,"url":"https://github.com/elastic/kibana/pull/179485","mergeCommit":{"message":"[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)\n\nCloses #179391 Summary\r\n\r\nWe were previously only calling `setSavedState` for the control group on\r\ndashboard navigation **when the control group was defined in the loaded\r\ndashboard** - however, if either the source or destination dashboard had\r\nzero controls, this caused problems on navigation:\r\n- If the source dashboard had at least one control and the destination\r\ndashboard had zero, the destination dashboard's control group\r\n`lastSavedInput` would **not** get set in `navigateToDashboard` since it\r\nis undefined - i.e. the `lastSavedInput` on the destination dashboard's\r\ncontrol group would **still be equal to** the `lastSavedInput` of the\r\nsource dashboard's control group after navigation. Therefore, hitting\r\n\"reset\" would replace the destination dashboard's empty control group\r\nwith the source's control group.\r\n- If the source dashboard had zero controls and the destination\r\ndashboard had at least one, the first step in navigation would work as\r\nexpected - the `lastSavedInput` of the destination dashboard would be\r\nset appropriately. However, upon hitting the browser back button and\r\ntriggering `navigateToDashboard` a second time, the source dashboard's\r\ncontrol group's `lastSavedInput` would **not** get set properly (since\r\nit is undefined) and would therefore still be equal to the\r\n`lastSavedInput` of the destination dashboard. Therefore, hitting\r\n\"reset\" would replace the source's empty control group with the\r\ndestination dashboard's controls.\r\n\r\nThis fixes the above scenarios by calling `setSavedState` on the control\r\ngroup **even if** the last saved control group state is undefined.\r\n\r\n### Race Condition Fix\r\n\r\nIn my testing for this, I discovered **another** bug caused by a race\r\ncondition where, on dashboard navigation, the subscription to the\r\ncontrol group's `initialize# Backport This will backport the following commits from `main` to `8.13`: - [[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)](#179485) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT subject was firing with the **wrong**\r\ninput, so the `lastSavedFilters` would be calculated incorrectly. This\r\ncaused the dashboard to get stuck in an unsaved changes state, like so:\r\n\r\n\r\n\r\nhttps://github.com/elastic/kibana/assets/8698078/14c553a9-21b3-40d0-96ac-0282e9e66911\r\n\r\n\r\n\r\nI fixed this by removing this subscription (it was messy anyway 🙈) and\r\nreplaced this logic with individual calls to\r\n`calculateFiltersFromSelections` - this should be easier to follow, and\r\nwe ensure that we are **always** doing this calculation with the\r\nexpected input. Since we aren't `awaiting` these calculations, it also\r\nshouldn't slow down the control group's initialization (which was the\r\noriginal reason for using a subscription).\r\n\r\n\r\n### Checklist\r\n\r\n\r\n- [x] This was checked for [cross-browser\r\ncompatibility](https://www.elastic.co/support/matrix#matrix_browsers)\r\n- [x] Flaky test runner -\r\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5583\r\n<br/>\r\n\r\n\r\n\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":"507f09d0b69a99f03f0c0cb19f10f1ea8584cd47"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.14.0","labelRegex":"^v8.14.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/179485","number":179485,"mergeCommit":{"message":"[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)\n\nCloses #179391 Summary\r\n\r\nWe were previously only calling `setSavedState` for the control group on\r\ndashboard navigation **when the control group was defined in the loaded\r\ndashboard** - however, if either the source or destination dashboard had\r\nzero controls, this caused problems on navigation:\r\n- If the source dashboard had at least one control and the destination\r\ndashboard had zero, the destination dashboard's control group\r\n`lastSavedInput` would **not** get set in `navigateToDashboard` since it\r\nis undefined - i.e. the `lastSavedInput` on the destination dashboard's\r\ncontrol group would **still be equal to** the `lastSavedInput` of the\r\nsource dashboard's control group after navigation. Therefore, hitting\r\n\"reset\" would replace the destination dashboard's empty control group\r\nwith the source's control group.\r\n- If the source dashboard had zero controls and the destination\r\ndashboard had at least one, the first step in navigation would work as\r\nexpected - the `lastSavedInput` of the destination dashboard would be\r\nset appropriately. However, upon hitting the browser back button and\r\ntriggering `navigateToDashboard` a second time, the source dashboard's\r\ncontrol group's `lastSavedInput` would **not** get set properly (since\r\nit is undefined) and would therefore still be equal to the\r\n`lastSavedInput` of the destination dashboard. Therefore, hitting\r\n\"reset\" would replace the source's empty control group with the\r\ndestination dashboard's controls.\r\n\r\nThis fixes the above scenarios by calling `setSavedState` on the control\r\ngroup **even if** the last saved control group state is undefined.\r\n\r\n### Race Condition Fix\r\n\r\nIn my testing for this, I discovered **another** bug caused by a race\r\ncondition where, on dashboard navigation, the subscription to the\r\ncontrol group's `initialize# Backport This will backport the following commits from `main` to `8.13`: - [[Dashboard] [Controls] Fix bug with drilldowns when source dashboard has no controls (#179485)](#179485) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT subject was firing with the **wrong**\r\ninput, so the `lastSavedFilters` would be calculated incorrectly. This\r\ncaused the dashboard to get stuck in an unsaved changes state, like so:\r\n\r\n\r\n\r\nhttps://github.com/elastic/kibana/assets/8698078/14c553a9-21b3-40d0-96ac-0282e9e66911\r\n\r\n\r\n\r\nI fixed this by removing this subscription (it was messy anyway 🙈) and\r\nreplaced this logic with individual calls to\r\n`calculateFiltersFromSelections` - this should be easier to follow, and\r\nwe ensure that we are **always** doing this calculation with the\r\nexpected input. Since we aren't `awaiting` these calculations, it also\r\nshouldn't slow down the control group's initialization (which was the\r\noriginal reason for using a subscription).\r\n\r\n\r\n### Checklist\r\n\r\n\r\n- [x] This was checked for [cross-browser\r\ncompatibility](https://www.elastic.co/support/matrix#matrix_browsers)\r\n- [x] Flaky test runner -\r\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5583\r\n<br/>\r\n\r\n\r\n\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":"507f09d0b69a99f03f0c0cb19f10f1ea8584cd47"}}]}] BACKPORT-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #179391
Summary
We were previously only calling
setSavedStatefor the control group on dashboard navigation when the control group was defined in the loaded dashboard - however, if either the source or destination dashboard had zero controls, this caused problems on navigation:lastSavedInputwould not get set innavigateToDashboardsince it is undefined - i.e. thelastSavedInputon the destination dashboard's control group would still be equal to thelastSavedInputof the source dashboard's control group after navigation. Therefore, hitting "reset" would replace the destination dashboard's empty control group with the source's control group.lastSavedInputof the destination dashboard would be set appropriately. However, upon hitting the browser back button and triggeringnavigateToDashboarda second time, the source dashboard's control group'slastSavedInputwould not get set properly (since it is undefined) and would therefore still be equal to thelastSavedInputof the destination dashboard. Therefore, hitting "reset" would replace the source's empty control group with the destination dashboard's controls.This fixes the above scenarios by calling
setSavedStateon the control group even if the last saved control group state is undefined.Race Condition Fix
In my testing for this, I discovered another bug caused by a race condition where, on dashboard navigation, the subscription to the control group's
initialize$subject was firing with the wrong input, so thelastSavedFilterswould be calculated incorrectly. This caused the dashboard to get stuck in an unsaved changes state, like so:Screen.Recording.2024-03-26.at.4.19.57.PM.mov
I fixed this by removing this subscription (it was messy anyway 🙈) and replaced this logic with individual calls to
calculateFiltersFromSelections- this should be easier to follow, and we ensure that we are always doing this calculation with the expected input. Since we aren'tawaitingthese calculations, it also shouldn't slow down the control group's initialization (which was the original reason for using a subscription).Checklist
For maintainers