-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Lens] Integrate searchSessionId into Lens app #86297
Conversation
Pinging @elastic/kibana-app (Team:KibanaApp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't test in depth yet, but two things:
- Is it resetting the search session id on refresh?
- Seems like it's not using the search session id for the suggestion panels
Yes.
You are quite right 😓 |
Added the session id for suggestions too: not sure what to test in there. |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good already, I just noticed one problem - if auto-refresh is used, the session id is not reset.
You can subscribe to the observable provided by the timefilter service in the data plugin to get notified and change the session id based on it (timefilter.getAutoRefreshFetch$()
).
If you do this, you can probably remove the subscriptions in the workspace and suggestion panels as they would get refetch automatically because of the incoming session id change - simplifying the code there as a little bonus :)
Line 365 in daa92c3
const autoRefreshFetch$ = useMemo(() => timefilter.getAutoRefreshFetch$(), [timefilter]); |
kibana/x-pack/plugins/lens/public/editor_frame_service/editor_frame/suggestion_panel.tsx
Line 274 in 928687b
const autoRefreshFetch$ = plugins.data.query.timefilter.timefilter.getAutoRefreshFetch$(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran into exactly the same problem as you are, which is that the API of onAppLeave
is unintuitive. We will need to find another solution to clearing searchSessionId.
@@ -205,6 +212,8 @@ export function App({ | |||
|
|||
useEffect(() => { | |||
onAppLeave((actions) => { | |||
// Clear the session when leaving Lens | |||
data.search.session.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely should not be adding side effects to the onAppLeave
handler because of how it's called. The onAppLeave
function is executed immediately, and is not executed when the user tries to leave. Basically it sets up a state that says "if the user were to leave in the future, prevent them".
What this means is that I don't think we have a reliable way to make a side effect happen as the user is leaving, and I don't think we should be adding any side effects to the onAppLeave
handlers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I guess we can put it in an unmount handler (e.g. useUnmount() )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did some investigation on this area:
- during the saving process, no problem with that, as the clear can be explicitly set
- otherwise if the user clicks on another plugin/app there's no other way to intercept it within Lens and clear the session. The session check happens before the component get unmounted leading to an error page. Note that this error page happens only on the
dev
environment, while in production the session gets cleared.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed with @flash1293 and found a simpler solution to that
dateRange: { | ||
fromDate: dateRange.from, | ||
toDate: dateRange.to, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we're using the timeFilter
manager instead now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code was already using the timeFilter
, but this code here was covering the scenario where the data didn't change but we want the state to trigger a new render ("Refresh" click).
Previously when the dateRange
values changed the state was update twice with the same content, triggering a double rendering. Now this scenario is covered by the timeFilter
subscription.
In case of no dateRange
change ("Refresh" button), the session id is regenerated triggering a re-render now.
We still need the dateRange
state, but we can reduce the number of time we update it.
@@ -89,6 +89,7 @@ export function App({ | |||
isSaveModalVisible: false, | |||
indicateNoData: false, | |||
isSaveable: false, | |||
searchSessionId: data.search.session.start(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove dateRange
from the LensAppState
now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved the dateRange
out of state in the last commit. An object reference needs to be still hold for the frame
component, but there's a single source of truth now for it.
/> | ||
); | ||
}, [plugins.data.query.timefilter.timefilter, ExpressionRendererComponent]); | ||
}, [frame.searchSessionId, ExpressionRendererComponent]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes the component to get renewed each time the session id changes, which causes the loading bug again that got fixed with #86092
Please either put the search session id in a ref as well to avoid that or remove the AutoRefreshExpressionRenderer
completely and just pass session id and search context down to the place where the component is actually used. With both of these approaches we can make sure the expression loader is not destroyed and re-created for each change.
I'm also seeing duplicated requests for the suggestions, but those might be caused by the same problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and works as expected. The issue with double fetch is caused by another problem, I will create a separate PR to fix
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Async chunks
Distributable file count
Page load bundle
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes LGTM!
* master: (108 commits) [DOCS] Refreshes Data Visualizer screenshot (elastic#87017) [Security Solution] Change 'anti-virus' text to 'antivirus' (elastic#87001) [securitySolution/cypress] temporarily limit to PRs [AppServices/Examples] Add the example for Reporting integration (elastic#82091) [Build Chromium] Improve git checkout (elastic#83225) Deprecate `services.callCluster` in alerts and actions executors (elastic#86474) [Security Solution] Use system node version for Cypress and increase exec command timeout (elastic#86985) [Lens] Add more chart editor tests based on the debug state (elastic#86750) [Lens] Integrate searchSessionId into Lens app (elastic#86297) skip "pagination updates results and page number" elastic#86975 skip "Custom detection rules" elastic#83772 [logging/json] use merge from kbn/std (elastic#86330) skip network and timeline inspection. elastic#85677, elastic#85678 skip "adds correctly a filter to the global search bar" elastic#86552 [ftr/flags] improve help text (elastic#86971) skip "Fields Browser rendering. elastic#60209 skip "Closes and opens alerts" elastic#83773 [Security Solution] Skip failing Cypress tests (elastic#86967) Removes archives (elastic#86537) [ML] Fix charts grid on the Anomaly Explorer page (elastic#86904) ...
* master: (72 commits) [DOCS] Refreshes Data Visualizer screenshot (elastic#87017) [Security Solution] Change 'anti-virus' text to 'antivirus' (elastic#87001) [securitySolution/cypress] temporarily limit to PRs [AppServices/Examples] Add the example for Reporting integration (elastic#82091) [Build Chromium] Improve git checkout (elastic#83225) Deprecate `services.callCluster` in alerts and actions executors (elastic#86474) [Security Solution] Use system node version for Cypress and increase exec command timeout (elastic#86985) [Lens] Add more chart editor tests based on the debug state (elastic#86750) [Lens] Integrate searchSessionId into Lens app (elastic#86297) skip "pagination updates results and page number" elastic#86975 skip "Custom detection rules" elastic#83772 [logging/json] use merge from kbn/std (elastic#86330) skip network and timeline inspection. elastic#85677, elastic#85678 skip "adds correctly a filter to the global search bar" elastic#86552 [ftr/flags] improve help text (elastic#86971) skip "Fields Browser rendering. elastic#60209 skip "Closes and opens alerts" elastic#83773 [Security Solution] Skip failing Cypress tests (elastic#86967) Removes archives (elastic#86537) [ML] Fix charts grid on the Anomaly Explorer page (elastic#86904) ...
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
2 similar comments
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Summary
Fix: #85517
the aim of the PR is to integrate the
searchSessionId
parameter in the LensEditorFrame
component.During the integration it was noticed that there were duplicate state updates on filter updates: that led to a refactor of the state update process to remove the duplications.
searchSessionId
on Editor open/landingsearchSessionId
mock to workManual tests have been performed to test various app leave flows. They should all be covered now, but any feedback on this side is welcome.
Checklist