[Embeddables] Serialized State Only by ThomThomson · Pull Request #215947 · elastic/kibana

ThomThomson · 2025-03-25T19:27:27Z

Closes #205531
Closes #219877.
Closes #213153
Closes #150920
Closes #203130

Overview

The embeddable framework has two types of state: SerializedState and RuntimeState.

SerializedState is the form of the state when saved into a Dashboard saved object. I.e. the References are extracted, and state saved externally (by reference) is removed. In contrast RuntimeState is an exact snapshot of the state used by the embeddable to render.

Exposing SerializedState and RuntimeState was a mistake that caused numerous regressions and architectural complexities.

This PR simplifies the embeddable framework by only exposing SerializedState. RuntimeState stays localized to the embeddable implementation and is never leaked to the embeddable framework.

Whats changed

ReactEmbeddableFactory<SerializedState, RuntimeState, Api> => EmbeddableFactory<SerializedState, Api>
deserializeState removed from embeddable factory. Instead, SerializedState is passed directly into buildEmbeddable.
buildEmbeddable parameter buildApi replaced with finalizeApi. buildApi({ api, comparators }) => finalizeApi(api).
The embeddable framework previously used its knowledge of RuntimeState to setup and monitor unsaved changes. Now, unsaved changes setup is pushed down to the embeddable implementation since the embeddable framework no longer has knowledge of embeddable RuntimeState.

Reviewer instructions

Please prioritize reviews. This is a large effort from our team and is blocking many other initiatives. Getting this merged is a top priority.

This is a large change that would best be reviewed by manually testing the changes

adding/editing your embeddable types
Ensuring dashboard shows unsaved changes as expected
Ensuring dashboard resets unsaved changes as expected
Ensuring dashboard does not show unsaved changes after save and reset
Returning to a dashboard with unsaved changes renders embeddables with those unsaved changes

… for eui markdown

…ansfer service (#216232) Fixes #213153 ## Summary This PR ensures that the embeddable state transfer service **exclusively** uases serialized state. Previously, the transfer service accepted **either** runtime state or serialized state - but we are in the process of removing the concept of "runtime state" for embeddables (at least as far as the Dashboard is concerned), and this is one step towards that goal. Note that this PR is built off the subset of "embeddable state transfer service related" changes from #215416 - all I did was clean up these changes, finalized some of the cases that were missed in the original draft, and updated tests as necessary. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

…ized-state' into embeddable-serialized-state

…anges initializer.

Also updates state manager API

…ot provided (#218186)

…ed-state

…itle (#218369)

_This PR does not need to be reviewed by external teams. This PR merges into a feature branch that Kibana presentation team is working on to convert the embeddable framework to only expose serialized state. Your team will be pinged for review once the work is complete and the final PR opens that merges the feature branch into main._ ## Summary Updates the Field list example embeddable to serialized state only. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…ized state only (#218270) _This PR does not need to be reviewed by external teams. This PR merges into a feature branch that Kibana presentation team is working on to convert the embeddable framework to only expose serialized state. Your team will be pinged for review once the work is complete and the final PR opens that merges the feature branch into main._ Converts the SLO embeddable to serialized state only. ## Testing this PR Create an SLO using the "How to Test" section in the description of [this PR](#179147). --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

_This PR does not need to be reviewed by external teams. This PR merges into a feature branch that Kibana presentation team is working on to convert the embeddable framework to only expose serialized state. Your team will be pinged for review once the work is complete and the final PR opens that merges the feature branch into main._ Converts the SLO alerts embeddable to serialized state only. ## Testing this PR Create an SLO using the "How to Test" section in the description of [this PR](#179147). --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…te only (#218461) _This PR does not need to be reviewed by external teams. This PR merges into a feature branch that Kibana presentation team is working on to convert the embeddable framework to only expose serialized state. Your team will be pinged for review once the work is complete and the final PR opens that merges the feature branch into main._ ## Summary Convert SLO burn rate to serialized state only ## Testing this PR Create an SLO using the "How to Test" section in the description of [this PR](#179147).

## Summary This PR removes runtime state from the example data table embeddable --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

nreese · 2025-04-16T19:52:40Z

@elasticmachine merge upstream

nreese · 2025-04-17T13:57:42Z

@elasticmachine merge upstream

nreese · 2025-04-18T16:48:13Z

@elasticmachine merge upstream

nreese · 2025-05-06T21:55:47Z

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

Closes elastic#205531 Closes elastic#219877. Closes elastic#213153 Closes elastic#150920 Closes elastic#203130 ### Overview The embeddable framework has two types of state: `SerializedState` and `RuntimeState`. `SerializedState` is the form of the state when saved into a Dashboard saved object. I.e. the References are extracted, and state saved externally (by reference) is removed. In contrast `RuntimeState` is an exact snapshot of the state used by the embeddable to render. Exposing SerializedState and RuntimeState was a mistake that caused numerous regressions and architectural complexities. This PR simplifies the embeddable framework by only exposing `SerializedState`. `RuntimeState` stays localized to the embeddable implementation and is never leaked to the embeddable framework. ### Whats changed * `ReactEmbeddableFactory<SerializedState, RuntimeState, Api>` => `EmbeddableFactory<SerializedState, Api>` * `deserializeState` removed from embeddable factory. Instead, `SerializedState` is passed directly into `buildEmbeddable`. * `buildEmbeddable` parameter `buildApi` replaced with `finalizeApi`. `buildApi({ api, comparators })` => `finalizeApi(api)`. * The embeddable framework previously used its knowledge of `RuntimeState` to setup and monitor unsaved changes. Now, unsaved changes setup is pushed down to the embeddable implementation since the embeddable framework no longer has knowledge of embeddable RuntimeState. ### Reviewer instructions Please prioritize reviews. This is a large effort from our team and is blocking many other initiatives. Getting this merged is a top priority. This is a large change that would best be reviewed by manually testing the changes * adding/editing your embeddable types * Ensuring dashboard shows unsaved changes as expected * Ensuring dashboard resets unsaved changes as expected * Ensuring dashboard does not show unsaved changes after save and reset * Returning to a dashboard with unsaved changes renders embeddables with those unsaved changes --------- Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com> Co-authored-by: Nathan Reese <reese.nathan@elastic.co> Co-authored-by: Nick Peihl <nick.peihl@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Catherine Liu <catherine.liu@elastic.co> Co-authored-by: Ola Pawlus <98127445+olapawlus@users.noreply.github.com> (cherry picked from commit 3e882d8) # Conflicts: # packages/kbn-optimizer/limits.yml # src/platform/plugins/shared/dashboard/public/dashboard_app/top_nav/share/show_share_modal.tsx # src/platform/plugins/shared/discover/public/embeddable/get_search_embeddable_factory.tsx # src/platform/plugins/shared/unified_doc_viewer/public/components/observability/traces/components/trace.tsx # x-pack/platform/plugins/shared/aiops/public/embeddables/change_point_chart/embeddable_change_point_chart_factory.tsx # x-pack/platform/plugins/shared/aiops/public/embeddables/log_rate_analysis/embeddable_log_rate_analysis_factory.tsx # x-pack/platform/plugins/shared/aiops/public/embeddables/pattern_analysis/embeddable_pattern_analysis_factory.tsx # x-pack/platform/plugins/shared/lens/public/plugin.ts # x-pack/platform/plugins/shared/ml/public/plugin.ts # x-pack/solutions/observability/plugins/apm/public/embeddable/trace_waterfall/react_embeddable_factory.tsx # x-pack/solutions/observability/plugins/apm/tsconfig.json # x-pack/solutions/observability/plugins/infra/public/components/log_stream/log_stream_react_embeddable.tsx

# Backport This will backport the following commits from `main` to `8.19`: - [[Embeddables] Serialized State Only (#215947)](#215947)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  --------- Co-authored-by: Devon Thomson <devon.thomson@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Fixes #221545 ### Background #215947 refactored [ControlGroupRenderer](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/controls/public/control_group/control_group_renderer/control_group_renderer.tsx) The regression is caused by this line changing `await getCreationOptions?.(getDefaultControlGroupRuntimeState(), controlGroupStateBuilder)` to `getCreationOptions(defaultRuntimeState, controlGroupStateBuilder)`. Opening the SLO view caused https://github.com/elastic/kibana/blob/main/x-pack/solutions/observability/plugins/slo/public/pages/slos/components/common/quick_filters.tsx#L72 to mutate `defaultRuntimeState`, and populate `initialChildControlState` with `slo-status-filter` and `slo-tags-filter`. Then when returning to Alerts view, `defaultRuntimeState.initialChildControlState` contained the controls from SLO page. ### Fix This PR resolves the issue by passing a new object to `getCreationOptions` so that `defaultRuntimeState` can not be polluted by consumers. ### Test steps * Start kibana with `yarn start` * Go license page and install 30 day trial license * In seperate window, run ``` node x-pack/scripts/data_forge.js \ --events-per-cycle 100 \ --lookback now-7d \ --dataset fake_stack \ --install-kibana-assets \ --kibana-url http://localhost:5601/<basePath> ``` * In SLO, create an SLO with the following ([more details](https://github.com/elastic/kibana/blob/main/x-pack/solutions/observability/plugins/slo/dev_docs/slo.md)) * Type: Custom Query * Index: Admin Console * Good (query): http.response.status_code < 500 * Total (query): http.response.status_code : * * toggle between SLO and alerts page and verify controls in alerts page do not grow after each visit to SLO page

Fixes elastic#221545 ### Background elastic#215947 refactored [ControlGroupRenderer](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/controls/public/control_group/control_group_renderer/control_group_renderer.tsx) The regression is caused by this line changing `await getCreationOptions?.(getDefaultControlGroupRuntimeState(), controlGroupStateBuilder)` to `getCreationOptions(defaultRuntimeState, controlGroupStateBuilder)`. Opening the SLO view caused https://github.com/elastic/kibana/blob/main/x-pack/solutions/observability/plugins/slo/public/pages/slos/components/common/quick_filters.tsx#L72 to mutate `defaultRuntimeState`, and populate `initialChildControlState` with `slo-status-filter` and `slo-tags-filter`. Then when returning to Alerts view, `defaultRuntimeState.initialChildControlState` contained the controls from SLO page. ### Fix This PR resolves the issue by passing a new object to `getCreationOptions` so that `defaultRuntimeState` can not be polluted by consumers. ### Test steps * Start kibana with `yarn start` * Go license page and install 30 day trial license * In seperate window, run ``` node x-pack/scripts/data_forge.js \ --events-per-cycle 100 \ --lookback now-7d \ --dataset fake_stack \ --install-kibana-assets \ --kibana-url http://localhost:5601/<basePath> ``` * In SLO, create an SLO with the following ([more details](https://github.com/elastic/kibana/blob/main/x-pack/solutions/observability/plugins/slo/dev_docs/slo.md)) * Type: Custom Query * Index: Admin Console * Good (query): http.response.status_code < 500 * Total (query): http.response.status_code : * * toggle between SLO and alerts page and verify controls in alerts page do not grow after each visit to SLO page (cherry picked from commit 3398573)

# Backport This will backport the following commits from `main` to `8.19`: - [[Alerts] fix Duplicated filters are shown (#221678)](#221678)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Nathan Reese <reese.nathan@elastic.co>

Closes elastic#205531 Closes elastic#219877. Closes elastic#213153 Closes elastic#150920 Closes elastic#203130 ### Overview The embeddable framework has two types of state: `SerializedState` and `RuntimeState`. `SerializedState` is the form of the state when saved into a Dashboard saved object. I.e. the References are extracted, and state saved externally (by reference) is removed. In contrast `RuntimeState` is an exact snapshot of the state used by the embeddable to render. Exposing SerializedState and RuntimeState was a mistake that caused numerous regressions and architectural complexities. This PR simplifies the embeddable framework by only exposing `SerializedState`. `RuntimeState` stays localized to the embeddable implementation and is never leaked to the embeddable framework. ### Whats changed * `ReactEmbeddableFactory<SerializedState, RuntimeState, Api>` => `EmbeddableFactory<SerializedState, Api>` * `deserializeState` removed from embeddable factory. Instead, `SerializedState` is passed directly into `buildEmbeddable`. * `buildEmbeddable` parameter `buildApi` replaced with `finalizeApi`. `buildApi({ api, comparators })` => `finalizeApi(api)`. * The embeddable framework previously used its knowledge of `RuntimeState` to setup and monitor unsaved changes. Now, unsaved changes setup is pushed down to the embeddable implementation since the embeddable framework no longer has knowledge of embeddable RuntimeState. ### Reviewer instructions Please prioritize reviews. This is a large effort from our team and is blocking many other initiatives. Getting this merged is a top priority. This is a large change that would best be reviewed by manually testing the changes * adding/editing your embeddable types * Ensuring dashboard shows unsaved changes as expected * Ensuring dashboard resets unsaved changes as expected * Ensuring dashboard does not show unsaved changes after save and reset * Returning to a dashboard with unsaved changes renders embeddables with those unsaved changes --------- Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com> Co-authored-by: Nathan Reese <reese.nathan@elastic.co> Co-authored-by: Nick Peihl <nick.peihl@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Catherine Liu <catherine.liu@elastic.co> Co-authored-by: Ola Pawlus <98127445+olapawlus@users.noreply.github.com>

Fixes elastic#221545 ### Background elastic#215947 refactored [ControlGroupRenderer](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/controls/public/control_group/control_group_renderer/control_group_renderer.tsx) The regression is caused by this line changing `await getCreationOptions?.(getDefaultControlGroupRuntimeState(), controlGroupStateBuilder)` to `getCreationOptions(defaultRuntimeState, controlGroupStateBuilder)`. Opening the SLO view caused https://github.com/elastic/kibana/blob/main/x-pack/solutions/observability/plugins/slo/public/pages/slos/components/common/quick_filters.tsx#L72 to mutate `defaultRuntimeState`, and populate `initialChildControlState` with `slo-status-filter` and `slo-tags-filter`. Then when returning to Alerts view, `defaultRuntimeState.initialChildControlState` contained the controls from SLO page. ### Fix This PR resolves the issue by passing a new object to `getCreationOptions` so that `defaultRuntimeState` can not be polluted by consumers. ### Test steps * Start kibana with `yarn start` * Go license page and install 30 day trial license * In seperate window, run ``` node x-pack/scripts/data_forge.js \ --events-per-cycle 100 \ --lookback now-7d \ --dataset fake_stack \ --install-kibana-assets \ --kibana-url http://localhost:5601/<basePath> ``` * In SLO, create an SLO with the following ([more details](https://github.com/elastic/kibana/blob/main/x-pack/solutions/observability/plugins/slo/dev_docs/slo.md)) * Type: Custom Query * Index: Admin Console * Good (query): http.response.status_code < 500 * Total (query): http.response.status_code : * * toggle between SLO and alerts page and verify controls in alerts page do not grow after each visit to SLO page

Closes elastic#205531 Closes elastic#219877. Closes elastic#213153 Closes elastic#150920 Closes elastic#203130 ### Overview The embeddable framework has two types of state: `SerializedState` and `RuntimeState`. `SerializedState` is the form of the state when saved into a Dashboard saved object. I.e. the References are extracted, and state saved externally (by reference) is removed. In contrast `RuntimeState` is an exact snapshot of the state used by the embeddable to render. Exposing SerializedState and RuntimeState was a mistake that caused numerous regressions and architectural complexities. This PR simplifies the embeddable framework by only exposing `SerializedState`. `RuntimeState` stays localized to the embeddable implementation and is never leaked to the embeddable framework. ### Whats changed * `ReactEmbeddableFactory<SerializedState, RuntimeState, Api>` => `EmbeddableFactory<SerializedState, Api>` * `deserializeState` removed from embeddable factory. Instead, `SerializedState` is passed directly into `buildEmbeddable`. * `buildEmbeddable` parameter `buildApi` replaced with `finalizeApi`. `buildApi({ api, comparators })` => `finalizeApi(api)`. * The embeddable framework previously used its knowledge of `RuntimeState` to setup and monitor unsaved changes. Now, unsaved changes setup is pushed down to the embeddable implementation since the embeddable framework no longer has knowledge of embeddable RuntimeState. ### Reviewer instructions Please prioritize reviews. This is a large effort from our team and is blocking many other initiatives. Getting this merged is a top priority. This is a large change that would best be reviewed by manually testing the changes * adding/editing your embeddable types * Ensuring dashboard shows unsaved changes as expected * Ensuring dashboard resets unsaved changes as expected * Ensuring dashboard does not show unsaved changes after save and reset * Returning to a dashboard with unsaved changes renders embeddables with those unsaved changes --------- Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com> Co-authored-by: Nathan Reese <reese.nathan@elastic.co> Co-authored-by: Nick Peihl <nick.peihl@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Catherine Liu <catherine.liu@elastic.co> Co-authored-by: Ola Pawlus <98127445+olapawlus@users.noreply.github.com>

## Summary Cherry-picked c528ca0 from #215947. This registers the ML embeddable synchronously to avoid a racing condition where the dashboard could try to render an ML embeddable before the embeddable is available. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary The issue was a regression caused by #215947 where the wrong serialized state was used when cloning the panel fix #227831 fixes #226970 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary The issue was a regression caused by elastic#215947 where the wrong serialized state was used when cloning the panel fix elastic#227831 fixes elastic#226970 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 120bb3d)

# Backport This will backport the following commits from `main` to `9.1`: - [[TSVB] Serialise the actual vis on clone (#227882)](#227882)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>

# Backport This will backport the following commits from `main` to `8.19`: - [[TSVB] Serialise the actual vis on clone (#227882)](#227882)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>

## Summary The issue was a regression caused by elastic#215947 where the wrong serialized state was used when cloning the panel fix elastic#227831 fixes elastic#226970 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

@nickpeihl

## Summary This PR tries to apply a patch to a logic that is not very clear about what a serialized state is and how this is used to evaluate if a dashboard has unsaved changes or not. The current implementation leverage the type `SerializedPanelState` that has a `rawState` property and a `references` array. https://github.com/elastic/kibana/blob/2eb9972ea52589fc2aab16f17bbc99cfedf76783/src/platform/packages/shared/presentation/presentation_publishing/interfaces/has_serializable_state.ts#L12-L19 This type is the result of the call to the passed method called `serializeState`, an as described in the type, the references are extracted. To my understanding, extracted refers to the fact that the `rawState` should only have a link/name to an external reference, and should not contain any trace of the original referenced object id. If this is the right way to understand that type definition, the associated method and the operation of `reference extraction` then I'm inclined to say that the current implementation of `initializeUnsavedChanges` doesn't take in consideration the `references` array in the equality check, because the only property passed and used with the comparators is the `rawState` as seen here: https://github.com/elastic/kibana/blob/c9b441ec50dc8dc3c9180e1412019c695199909f/src/platform/packages/shared/presentation/presentation_containers/interfaces/unsaved_changes/initialize_unsaved_changes.ts#L48-L59 This can create unwanted situation where a change to the used references can be undetected by the "unsaved changes" method. One example is coming from the linked [issue](#228203) where TSVB was extracting the references as requested, replacing, on the serializedState, the `index_pattern: {id: "123abc"}` with a `index_pattern_ref_name: "metric_0_index_pattern"` and moving the actual index pattern references in the array outside the `rawState`. This generates the issue where switching an index pattern doesn't result in an unsaved change detected at the dashboard level because both the current rawState and the latest saved rawState are in fact the same (but not he references array). An AggBased visualization, that uses the same embeddable as TSVB, suffers from the same problem. If you the switch the data view the change is not picked up. TSVB and AggBased issues are both regression coming from #215947 (I tested before and after that PR) Lens probably has the same issue, but due to a wrong implementation, the `rawState` also has it's own copy of the `references` array that is replaced at the time of the references injection, but that is not removed at the time of the reference extractions (yes it is saved in the SO as part of the attributes and could differ from the dashboard reference array if a reference id has been changed in the dashboard). (I had also a discussion with @nickpeihl about this wrong behaviour). So basically Lens, for a wrong implementation, doesn't suffer of this problem, but if we are going to implement the reference extraction correctly will suffer of this issue. The implementation is simple, but can be definitely improved. One thing that is not clear now is the following: The dashboard is saved after the first click to the `Save` button, but it will keep showing the `usaved changes` until: - you click save again - or you refresh the page So basically the changes are correctly saved to ES but the latestSavedState is not updated immediately. I believe this is an issue with the current `Spaghetti Observable` used here. fix #228203 ## Release Note Fixes a bug that prevented saving linked TSVB visualizations when change data view. --------- Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>

@nickpeihl

…228685) ## Summary This PR tries to apply a patch to a logic that is not very clear about what a serialized state is and how this is used to evaluate if a dashboard has unsaved changes or not. The current implementation leverage the type `SerializedPanelState` that has a `rawState` property and a `references` array. https://github.com/elastic/kibana/blob/2eb9972ea52589fc2aab16f17bbc99cfedf76783/src/platform/packages/shared/presentation/presentation_publishing/interfaces/has_serializable_state.ts#L12-L19 This type is the result of the call to the passed method called `serializeState`, an as described in the type, the references are extracted. To my understanding, extracted refers to the fact that the `rawState` should only have a link/name to an external reference, and should not contain any trace of the original referenced object id. If this is the right way to understand that type definition, the associated method and the operation of `reference extraction` then I'm inclined to say that the current implementation of `initializeUnsavedChanges` doesn't take in consideration the `references` array in the equality check, because the only property passed and used with the comparators is the `rawState` as seen here: https://github.com/elastic/kibana/blob/c9b441ec50dc8dc3c9180e1412019c695199909f/src/platform/packages/shared/presentation/presentation_containers/interfaces/unsaved_changes/initialize_unsaved_changes.ts#L48-L59 This can create unwanted situation where a change to the used references can be undetected by the "unsaved changes" method. One example is coming from the linked [issue](elastic#228203) where TSVB was extracting the references as requested, replacing, on the serializedState, the `index_pattern: {id: "123abc"}` with a `index_pattern_ref_name: "metric_0_index_pattern"` and moving the actual index pattern references in the array outside the `rawState`. This generates the issue where switching an index pattern doesn't result in an unsaved change detected at the dashboard level because both the current rawState and the latest saved rawState are in fact the same (but not he references array). An AggBased visualization, that uses the same embeddable as TSVB, suffers from the same problem. If you the switch the data view the change is not picked up. TSVB and AggBased issues are both regression coming from elastic#215947 (I tested before and after that PR) Lens probably has the same issue, but due to a wrong implementation, the `rawState` also has it's own copy of the `references` array that is replaced at the time of the references injection, but that is not removed at the time of the reference extractions (yes it is saved in the SO as part of the attributes and could differ from the dashboard reference array if a reference id has been changed in the dashboard). (I had also a discussion with @nickpeihl about this wrong behaviour). So basically Lens, for a wrong implementation, doesn't suffer of this problem, but if we are going to implement the reference extraction correctly will suffer of this issue. The implementation is simple, but can be definitely improved. One thing that is not clear now is the following: The dashboard is saved after the first click to the `Save` button, but it will keep showing the `usaved changes` until: - you click save again - or you refresh the page So basically the changes are correctly saved to ES but the latestSavedState is not updated immediately. I believe this is an issue with the current `Spaghetti Observable` used here. fix elastic#228203 ## Release Note Fixes a bug that prevented saving linked TSVB visualizations when change data view. --------- Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com> (cherry picked from commit 2747360) # Conflicts: # src/platform/plugins/shared/dashboard/public/dashboard_api/get_dashboard_api.ts

@nickpeihl

…228685) ## Summary This PR tries to apply a patch to a logic that is not very clear about what a serialized state is and how this is used to evaluate if a dashboard has unsaved changes or not. The current implementation leverage the type `SerializedPanelState` that has a `rawState` property and a `references` array. https://github.com/elastic/kibana/blob/2eb9972ea52589fc2aab16f17bbc99cfedf76783/src/platform/packages/shared/presentation/presentation_publishing/interfaces/has_serializable_state.ts#L12-L19 This type is the result of the call to the passed method called `serializeState`, an as described in the type, the references are extracted. To my understanding, extracted refers to the fact that the `rawState` should only have a link/name to an external reference, and should not contain any trace of the original referenced object id. If this is the right way to understand that type definition, the associated method and the operation of `reference extraction` then I'm inclined to say that the current implementation of `initializeUnsavedChanges` doesn't take in consideration the `references` array in the equality check, because the only property passed and used with the comparators is the `rawState` as seen here: https://github.com/elastic/kibana/blob/c9b441ec50dc8dc3c9180e1412019c695199909f/src/platform/packages/shared/presentation/presentation_containers/interfaces/unsaved_changes/initialize_unsaved_changes.ts#L48-L59 This can create unwanted situation where a change to the used references can be undetected by the "unsaved changes" method. One example is coming from the linked [issue](elastic#228203) where TSVB was extracting the references as requested, replacing, on the serializedState, the `index_pattern: {id: "123abc"}` with a `index_pattern_ref_name: "metric_0_index_pattern"` and moving the actual index pattern references in the array outside the `rawState`. This generates the issue where switching an index pattern doesn't result in an unsaved change detected at the dashboard level because both the current rawState and the latest saved rawState are in fact the same (but not he references array). An AggBased visualization, that uses the same embeddable as TSVB, suffers from the same problem. If you the switch the data view the change is not picked up. TSVB and AggBased issues are both regression coming from elastic#215947 (I tested before and after that PR) Lens probably has the same issue, but due to a wrong implementation, the `rawState` also has it's own copy of the `references` array that is replaced at the time of the references injection, but that is not removed at the time of the reference extractions (yes it is saved in the SO as part of the attributes and could differ from the dashboard reference array if a reference id has been changed in the dashboard). (I had also a discussion with @nickpeihl about this wrong behaviour). So basically Lens, for a wrong implementation, doesn't suffer of this problem, but if we are going to implement the reference extraction correctly will suffer of this issue. The implementation is simple, but can be definitely improved. One thing that is not clear now is the following: The dashboard is saved after the first click to the `Save` button, but it will keep showing the `usaved changes` until: - you click save again - or you refresh the page So basically the changes are correctly saved to ES but the latestSavedState is not updated immediately. I believe this is an issue with the current `Spaghetti Observable` used here. fix elastic#228203 ## Release Note Fixes a bug that prevented saving linked TSVB visualizations when change data view. --------- Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>

@nickpeihl

…228685) ## Summary This PR tries to apply a patch to a logic that is not very clear about what a serialized state is and how this is used to evaluate if a dashboard has unsaved changes or not. The current implementation leverage the type `SerializedPanelState` that has a `rawState` property and a `references` array. https://github.com/elastic/kibana/blob/2eb9972ea52589fc2aab16f17bbc99cfedf76783/src/platform/packages/shared/presentation/presentation_publishing/interfaces/has_serializable_state.ts#L12-L19 This type is the result of the call to the passed method called `serializeState`, an as described in the type, the references are extracted. To my understanding, extracted refers to the fact that the `rawState` should only have a link/name to an external reference, and should not contain any trace of the original referenced object id. If this is the right way to understand that type definition, the associated method and the operation of `reference extraction` then I'm inclined to say that the current implementation of `initializeUnsavedChanges` doesn't take in consideration the `references` array in the equality check, because the only property passed and used with the comparators is the `rawState` as seen here: https://github.com/elastic/kibana/blob/c9b441ec50dc8dc3c9180e1412019c695199909f/src/platform/packages/shared/presentation/presentation_containers/interfaces/unsaved_changes/initialize_unsaved_changes.ts#L48-L59 This can create unwanted situation where a change to the used references can be undetected by the "unsaved changes" method. One example is coming from the linked [issue](elastic#228203) where TSVB was extracting the references as requested, replacing, on the serializedState, the `index_pattern: {id: "123abc"}` with a `index_pattern_ref_name: "metric_0_index_pattern"` and moving the actual index pattern references in the array outside the `rawState`. This generates the issue where switching an index pattern doesn't result in an unsaved change detected at the dashboard level because both the current rawState and the latest saved rawState are in fact the same (but not he references array). An AggBased visualization, that uses the same embeddable as TSVB, suffers from the same problem. If you the switch the data view the change is not picked up. TSVB and AggBased issues are both regression coming from elastic#215947 (I tested before and after that PR) Lens probably has the same issue, but due to a wrong implementation, the `rawState` also has it's own copy of the `references` array that is replaced at the time of the references injection, but that is not removed at the time of the reference extractions (yes it is saved in the SO as part of the attributes and could differ from the dashboard reference array if a reference id has been changed in the dashboard). (I had also a discussion with @nickpeihl about this wrong behaviour). So basically Lens, for a wrong implementation, doesn't suffer of this problem, but if we are going to implement the reference extraction correctly will suffer of this issue. The implementation is simple, but can be definitely improved. One thing that is not clear now is the following: The dashboard is saved after the first click to the `Save` button, but it will keep showing the `usaved changes` until: - you click save again - or you refresh the page So basically the changes are correctly saved to ES but the latestSavedState is not updated immediately. I believe this is an issue with the current `Spaghetti Observable` used here. fix elastic#228203 ## Release Note Fixes a bug that prevented saving linked TSVB visualizations when change data view. --------- Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>

@nickpeihl

…228685) ## Summary This PR tries to apply a patch to a logic that is not very clear about what a serialized state is and how this is used to evaluate if a dashboard has unsaved changes or not. The current implementation leverage the type `SerializedPanelState` that has a `rawState` property and a `references` array. https://github.com/elastic/kibana/blob/2eb9972ea52589fc2aab16f17bbc99cfedf76783/src/platform/packages/shared/presentation/presentation_publishing/interfaces/has_serializable_state.ts#L12-L19 This type is the result of the call to the passed method called `serializeState`, an as described in the type, the references are extracted. To my understanding, extracted refers to the fact that the `rawState` should only have a link/name to an external reference, and should not contain any trace of the original referenced object id. If this is the right way to understand that type definition, the associated method and the operation of `reference extraction` then I'm inclined to say that the current implementation of `initializeUnsavedChanges` doesn't take in consideration the `references` array in the equality check, because the only property passed and used with the comparators is the `rawState` as seen here: https://github.com/elastic/kibana/blob/c9b441ec50dc8dc3c9180e1412019c695199909f/src/platform/packages/shared/presentation/presentation_containers/interfaces/unsaved_changes/initialize_unsaved_changes.ts#L48-L59 This can create unwanted situation where a change to the used references can be undetected by the "unsaved changes" method. One example is coming from the linked [issue](elastic#228203) where TSVB was extracting the references as requested, replacing, on the serializedState, the `index_pattern: {id: "123abc"}` with a `index_pattern_ref_name: "metric_0_index_pattern"` and moving the actual index pattern references in the array outside the `rawState`. This generates the issue where switching an index pattern doesn't result in an unsaved change detected at the dashboard level because both the current rawState and the latest saved rawState are in fact the same (but not he references array). An AggBased visualization, that uses the same embeddable as TSVB, suffers from the same problem. If you the switch the data view the change is not picked up. TSVB and AggBased issues are both regression coming from elastic#215947 (I tested before and after that PR) Lens probably has the same issue, but due to a wrong implementation, the `rawState` also has it's own copy of the `references` array that is replaced at the time of the references injection, but that is not removed at the time of the reference extractions (yes it is saved in the SO as part of the attributes and could differ from the dashboard reference array if a reference id has been changed in the dashboard). (I had also a discussion with @nickpeihl about this wrong behaviour). So basically Lens, for a wrong implementation, doesn't suffer of this problem, but if we are going to implement the reference extraction correctly will suffer of this issue. The implementation is simple, but can be definitely improved. One thing that is not clear now is the following: The dashboard is saved after the first click to the `Save` button, but it will keep showing the `usaved changes` until: - you click save again - or you refresh the page So basically the changes are correctly saved to ES but the latestSavedState is not updated immediately. I believe this is an issue with the current `Spaghetti Observable` used here. fix elastic#228203 ## Release Note Fixes a bug that prevented saving linked TSVB visualizations when change data view. --------- Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com> (cherry picked from commit 2747360) # Conflicts: # src/platform/plugins/shared/dashboard/public/dashboard_api/get_dashboard_api.ts

ThomThomson and others added 16 commits March 25, 2025 15:09

initial set up of new embeddable factory types.

16426a2

First pass of state manager. Messy version of state & unsaved changes…

07c26d6

… for eui markdown

Dashboard integration in progress.

a873bdd

Merge remote-tracking branch 'refs/remotes/upstream/embeddable-serial…

d4c0a7d

…ized-state' into embeddable-serialized-state

SerializedStateOnly Dashboard integration

8e7cd88

Use new state manager type for titles and markdown. set up unsaved ch…

7b3505d

…anges initializer.

convert search example embeddable (#217246)

df5191d

Migrate Map embeddable to serialized state only (#217351)

237928c

Migrate Visualize embeddable to serialized state only (#217736)

1c0574a

Also updates state manager API

Fix unlink from library (#217743)

0f155ec

[canvas] migrate canvas to serialized state only (#217874)

5b1dac2

convert Lens embeddable to serialized state only (#217911)

3ecdbaf

Discover session serialized state (#218015)

5ab2cf5

Tslint serialize state (#218026)

fa546d3

fix reading properties of undefined when currentChildState[uuid] is n…

777ee00

…ot provided (#218186)

ThomThomson force-pushed the embeddable-serialized-state branch from e4e735e to 777ee00 Compare April 15, 2025 18:48

ThomThomson and others added 7 commits April 15, 2025 14:56

Merge remote-tracking branch 'upstream/main' into embeddable-serializ…

b060605

…ed-state

update titleManger to implement PublishesTitle and PublishesWritableT…

8b8c21b

…itle (#218369)

[Serialized State Only] Data table embeddable (#218355)

7533eea

## Summary This PR removes runtime state from the example data table embeddable --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Merge branch 'main' into embeddable-serialized-state

be7e55c

elasticmachine and others added 2 commits April 17, 2025 15:57

Merge branch 'main' into embeddable-serialized-state

331f37d

Convert control group embeddable to serialized state only (#218370)

1e2d7d6

nreese mentioned this pull request May 22, 2025

[canvas] embeddables not refreshing on manual refresh or auto-refresh #221321

Closed

kdelemme mentioned this pull request May 26, 2025

[Alerts] Duplicated filters are shown #221545

Closed

nreese mentioned this pull request May 27, 2025

[Alerts] fix Duplicated filters are shown #221678

Merged

cqliu1 mentioned this pull request Jun 24, 2025

[Embeddable] Register ML embeddables synchronously #225110

Merged

9 tasks

This was referenced Jul 14, 2025

[TSVB] Serialise the actual vis on clone #227882

Merged

[TSVB] A cloned panel can't update the dataview #228203

Closed

This was referenced Jul 19, 2025

[TSVB] Fix missing unsaved changes on linked visualizations #228685

Merged

[AggBased Chart] Wrongly serialized timeRange causes unsaved changes events #228686

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Embeddables] Serialized State Only#215947

[Embeddables] Serialized State Only#215947
nreese merged 100 commits intomainfrom
embeddable-serialized-state

ThomThomson commented Mar 25, 2025 •

edited by kibanamachine

Loading

Uh oh!

nreese commented Apr 16, 2025

Uh oh!

nreese commented Apr 17, 2025

Uh oh!

nreese commented Apr 18, 2025

Uh oh!

nreese commented May 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

Conversation

ThomThomson commented Mar 25, 2025 • edited by kibanamachine Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Whats changed

Reviewer instructions

Uh oh!

nreese commented Apr 16, 2025

Uh oh!

nreese commented Apr 17, 2025

Uh oh!

nreese commented Apr 18, 2025

Uh oh!

nreese commented May 6, 2025

💚 All backports created successfully

Questions ?

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

ThomThomson commented Mar 25, 2025 •

edited by kibanamachine

Loading