[Dashboard][Lens][Visualize] Session is reset when cancelling editing embeddable

[flash1293]

Kibana version: master

Describe the bug: Editing a visualization from a dashboard retains the session to avoid sending requests to Elasticsearch. This works fine if the visualization is saved, but on using the "Cancel" button in Lens the session gets reset

Steps to reproduce:

1. Go to dashboard with a Lens(Visualize/Maps/any embeddable) panel
2. Edit Lens panel (session is reused)
3. Hit cancel
4. Dashboard loads with new session

Expected behavior:
Dashboard should load with the same session

[elasticmachine]

Pinging @elastic/kibana-vis-editors (Team:VisEditors)

[mbondyra]

I investigated a bit in this issue and the problem is that currently dashboard takes preserved searchSessionId from the incomingEmbeddable.searchSessionId. So we have 2 cases when cancelling:

1. When creating a new visualisation from the dashboard and cancelling, the saved object doesn't exist so there's no incomingEmbeddable to take the data from
2. When editing existing visualization, we could pass the incomingEmbeddable (we don't at the moment)

The problem is not Lens specific, but happens for Visualize/Maps and all the embeddables so firstly it would make sense to come up with the API how to pass the searchSessionId to the dashboard in case of cancelling. @ThomThomson, any thoughts?

[ThomThomson]

I think that when the session sharing feature was initially architected, the decision to place it inside incomingEmbeddable was made because the searchSessionId exists on the embeddable input already. Is that correct @flash1293?

It seems to me that the session sharing feature should be totally separated from the concept of incomingEmbeddable, because traveling around between different apps doesn't necessarily mean that you're building an embeddable. This will be even more the case when we start adding ways to view a visualize or lens config without even being in edit mode.

I think the best way forward is either

A: to build a section within the stateTransferService which explicitly handles searchSessionId sharing, or
B: to build a completely separate system (outside of the embeddable plugin) for sharing search sessions, by storing the activeSessionId in the session storage.

I would more likely lean towards option B because it's better to be explicit for these things. Either way, I don't think this is a VisEditors project, and should most likely be on the roadmap for @elastic/kibana-presentation and @elastic/kibana-app-services

[flash1293]

Agree with everything here @ThomThomson - I don't think the issue is severe enough to be worth a quick-n-dirty fix.

[flash1293]

Blocked on #121543

[stratoula]

This is not happening with the inline editing and the issue which would unblock thhis got closed so I am closing it