[Infra] Refactor useSearchSession hook
#203412
Assignees
Labels
Feature:ObsHosts
Hosts feature within Observability
Team:obs-ux-infra_services
Observability Infrastructure & Services User Experience Team
technical debt
Improvement of the software architecture and operational architecture
Comments
crespocarlos
added
bug
|
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
crespocarlos
added
technical debt
1 task
dej611
added a commit
that referenced
this issue
Dec 11, 2024
…3150) ## Summary Fixes #202266 This PR fixes the underline rerendering issue at the `useSearchApi` hook level, so any embeddable component who uses this hook would benefit from the fix. Ideally the props passed to the Lens component should be memoized, but this assumption would break many integrations as the previous embeddable component did take care of filtering duplicates. To test this: * Go to `Observability > Alerts > Manage rules` and `Add Rule`, pick the `Custom threshold` option and verify the infinite reload does not happen Once fixed this, another problem bubbled up with the brushing use case: when brushing a chart the chart was always one time range step behind. The other bug was due to the `fetch$(api)` function propagating a stale `data` search context who the Lens embeddable was relying on. To solve this other problem the following changes have been applied: * read the `searchSessionId` from the `api` directly (used for `autoRefresh`) * make sure to test the `Refresh` feature with both relative and absolute time ranges * read the `search context` from the `parentApi` directly if implements the `unifiedSearch` API * to test this, brush and check that the final time range matches the correct time range **Note**: the fundamental issue for the latter is `fetch$` not emitting the up-to-date `data` when the parentApi search context updates. The retrieved `data` is stale and one step behind, so it is not reliable. cc @elastic/kibana-presentation As @ThomThomson noticed in his test failure investigation another issue was found in this PR due to the wrong handling of the searchSessionId within the Observability page (for more details see [his analysis](#203150 (comment))). @markov00 and @crespocarlos helped risolve this problem with some additional changes on the Observability side of things: this will lead to some extra searchSessionId to be created, which will be eventually solved by Observability team [shortly moving away from the `searchSessionId` mechanism](#203412) ### 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 --------- Co-authored-by: Marco Vettorello <[email protected]> Co-authored-by: Carlos Crespo <[email protected]>
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Dec 11, 2024
…stic#203150) ## Summary Fixes elastic#202266 This PR fixes the underline rerendering issue at the `useSearchApi` hook level, so any embeddable component who uses this hook would benefit from the fix. Ideally the props passed to the Lens component should be memoized, but this assumption would break many integrations as the previous embeddable component did take care of filtering duplicates. To test this: * Go to `Observability > Alerts > Manage rules` and `Add Rule`, pick the `Custom threshold` option and verify the infinite reload does not happen Once fixed this, another problem bubbled up with the brushing use case: when brushing a chart the chart was always one time range step behind. The other bug was due to the `fetch$(api)` function propagating a stale `data` search context who the Lens embeddable was relying on. To solve this other problem the following changes have been applied: * read the `searchSessionId` from the `api` directly (used for `autoRefresh`) * make sure to test the `Refresh` feature with both relative and absolute time ranges * read the `search context` from the `parentApi` directly if implements the `unifiedSearch` API * to test this, brush and check that the final time range matches the correct time range **Note**: the fundamental issue for the latter is `fetch$` not emitting the up-to-date `data` when the parentApi search context updates. The retrieved `data` is stale and one step behind, so it is not reliable. cc @elastic/kibana-presentation As @ThomThomson noticed in his test failure investigation another issue was found in this PR due to the wrong handling of the searchSessionId within the Observability page (for more details see [his analysis](elastic#203150 (comment))). @markov00 and @crespocarlos helped risolve this problem with some additional changes on the Observability side of things: this will lead to some extra searchSessionId to be created, which will be eventually solved by Observability team [shortly moving away from the `searchSessionId` mechanism](elastic#203412) ### 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 --------- Co-authored-by: Marco Vettorello <[email protected]> Co-authored-by: Carlos Crespo <[email protected]> (cherry picked from commit d4194ba)
CAWilson94
pushed a commit
to CAWilson94/kibana
that referenced
this issue
Dec 12, 2024
…stic#203150) ## Summary Fixes elastic#202266 This PR fixes the underline rerendering issue at the `useSearchApi` hook level, so any embeddable component who uses this hook would benefit from the fix. Ideally the props passed to the Lens component should be memoized, but this assumption would break many integrations as the previous embeddable component did take care of filtering duplicates. To test this: * Go to `Observability > Alerts > Manage rules` and `Add Rule`, pick the `Custom threshold` option and verify the infinite reload does not happen Once fixed this, another problem bubbled up with the brushing use case: when brushing a chart the chart was always one time range step behind. The other bug was due to the `fetch$(api)` function propagating a stale `data` search context who the Lens embeddable was relying on. To solve this other problem the following changes have been applied: * read the `searchSessionId` from the `api` directly (used for `autoRefresh`) * make sure to test the `Refresh` feature with both relative and absolute time ranges * read the `search context` from the `parentApi` directly if implements the `unifiedSearch` API * to test this, brush and check that the final time range matches the correct time range **Note**: the fundamental issue for the latter is `fetch$` not emitting the up-to-date `data` when the parentApi search context updates. The retrieved `data` is stale and one step behind, so it is not reliable. cc @elastic/kibana-presentation As @ThomThomson noticed in his test failure investigation another issue was found in this PR due to the wrong handling of the searchSessionId within the Observability page (for more details see [his analysis](elastic#203150 (comment))). @markov00 and @crespocarlos helped risolve this problem with some additional changes on the Observability side of things: this will lead to some extra searchSessionId to be created, which will be eventually solved by Observability team [shortly moving away from the `searchSessionId` mechanism](elastic#203412) ### 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 --------- Co-authored-by: Marco Vettorello <[email protected]> Co-authored-by: Carlos Crespo <[email protected]>
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Jan 3, 2025
…mp based refresh (elastic#205338) ## Summary Refactoring `useSearchSession` to `useReloadRequestTime` to decouple the usage of search.session for refreshing, avoiding a re-rendering loop issue. This change is then propagated to various Lens charts to make use of that instead of relying on searchSessionId. Closes elastic#203412 ## How to test - Go to Infrastructure Inventory page in Observability - Enable Auto-Refresh - Click on a infra item (host/service/etc) to open the fly-out - Update the time range in the flyout - Things should update without spurious refreshes. --------- Co-authored-by: kibanamachine <[email protected]> (cherry picked from commit fe988fa)
kibanamachine
added a commit
that referenced
this issue
Jan 3, 2025
…imestamp based refresh (#205338) (#205521) # Backport This will backport the following commits from `main` to `8.x`: - [[Infra] Refactor useSearchSession to useReloadRequestTime for timestamp based refresh (#205338)](#205338) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Gonçalo Rica Pais da Silva","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-01-03T16:44:52Z","message":"[Infra] Refactor useSearchSession to useReloadRequestTime for timestamp based refresh (#205338)\n\n## Summary\r\n\r\nRefactoring `useSearchSession` to `useReloadRequestTime` to decouple the\r\nusage of search.session for refreshing, avoiding a re-rendering loop\r\nissue. This change is then propagated to various Lens charts to make use\r\nof that instead of relying on searchSessionId.\r\n\r\nCloses #203412\r\n\r\n## How to test\r\n\r\n- Go to Infrastructure Inventory page in Observability\r\n- Enable Auto-Refresh\r\n- Click on a infra item (host/service/etc) to open the fly-out\r\n- Update the time range in the flyout\r\n- Things should update without spurious refreshes.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"fe988fa55272a4ee6006a3a3ffc899a03fd4390c","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","Team:obs-ux-infra_services"],"title":"[Infra] Refactor useSearchSession to useReloadRequestTime for timestamp based refresh","number":205338,"url":"https://github.com/elastic/kibana/pull/205338","mergeCommit":{"message":"[Infra] Refactor useSearchSession to useReloadRequestTime for timestamp based refresh (#205338)\n\n## Summary\r\n\r\nRefactoring `useSearchSession` to `useReloadRequestTime` to decouple the\r\nusage of search.session for refreshing, avoiding a re-rendering loop\r\nissue. This change is then propagated to various Lens charts to make use\r\nof that instead of relying on searchSessionId.\r\n\r\nCloses #203412\r\n\r\n## How to test\r\n\r\n- Go to Infrastructure Inventory page in Observability\r\n- Enable Auto-Refresh\r\n- Click on a infra item (host/service/etc) to open the fly-out\r\n- Update the time range in the flyout\r\n- Things should update without spurious refreshes.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"fe988fa55272a4ee6006a3a3ffc899a03fd4390c"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/205338","number":205338,"mergeCommit":{"message":"[Infra] Refactor useSearchSession to useReloadRequestTime for timestamp based refresh (#205338)\n\n## Summary\r\n\r\nRefactoring `useSearchSession` to `useReloadRequestTime` to decouple the\r\nusage of search.session for refreshing, avoiding a re-rendering loop\r\nissue. This change is then propagated to various Lens charts to make use\r\nof that instead of relying on searchSessionId.\r\n\r\nCloses #203412\r\n\r\n## How to test\r\n\r\n- Go to Infrastructure Inventory page in Observability\r\n- Enable Auto-Refresh\r\n- Click on a infra item (host/service/etc) to open the fly-out\r\n- Update the time range in the flyout\r\n- Things should update without spurious refreshes.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"fe988fa55272a4ee6006a3a3ffc899a03fd4390c"}}]}] BACKPORT--> Co-authored-by: Gonçalo Rica Pais da Silva <[email protected]>
kowalczyk-krzysztof
pushed a commit
to kowalczyk-krzysztof/kibana
that referenced
this issue
Jan 7, 2025
…mp based refresh (elastic#205338) ## Summary Refactoring `useSearchSession` to `useReloadRequestTime` to decouple the usage of search.session for refreshing, avoiding a re-rendering loop issue. This change is then propagated to various Lens charts to make use of that instead of relying on searchSessionId. Closes elastic#203412 ## How to test - Go to Infrastructure Inventory page in Observability - Enable Auto-Refresh - Click on a infra item (host/service/etc) to open the fly-out - Update the time range in the flyout - Things should update without spurious refreshes. --------- Co-authored-by: kibanamachine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
As per #203150 (comment), the
useSearchSessionshouldn't rely onsearch.session. The UI needs to have a context that can be used to control when requests will be made and to force requests. Similar to APM'suse_time_range_id_context, but using timestamp instead.AC
useSearchSessionis renamedupdateSearchSessionIdis renameduseSearchSessiondoesn't usesearch.sessionnor creates a dependency on the UI withsearchSessionIdsearchSessionIdis replaced withlastReloadRequestTimeon usages of lens embeddableuseFetcherno longer usessearchSessionIdbut the new variable.The text was updated successfully, but these errors were encountered: