-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Discover] Refactor totalHits$ loading state handling to omit race conditions #196114
Conversation
/ci |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7137[✅] test/functional/apps/discover/group3/config.ts: 25/25 tests passed. |
/ci |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7138[✅] test/functional/apps/discover/group3/config.ts: 25/25 tests passed. |
/ci |
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
// dataSubjects.main$.subscribe((msg) => addLog('dataSubjects.main$', msg)); | ||
// dataSubjects.documents$.subscribe((msg) => addLog('dataSubjects.documents$', msg)); | ||
// dataSubjects.totalHits$.subscribe((msg) => addLog('dataSubjects.totalHits$', msg);); | ||
// Add window.ELASTIC_DISCOVER_LOGGER = 'debug' to see messages in console |
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.
uncommenting the code can be very helpful to unterstand data fetching observables race conditions, I think it's worth keeping it here
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 could be helpful to debug at least a part of the staff you mention in #165192 (comment) @jughosta
src/plugins/discover/public/application/main/components/layout/use_discover_histogram.ts
Outdated
Show resolved
Hide resolved
src/plugins/discover/public/application/main/components/layout/use_discover_histogram.ts
Outdated
Show resolved
Hide resolved
@@ -98,6 +98,8 @@ export function fetchAll( | |||
sendLoadingMsg(dataSubjects.totalHits$, { | |||
result: dataSubjects.totalHits$.getValue().result, | |||
}); | |||
} else { | |||
sendLoadingMsg(dataSubjects.totalHits$); |
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.
Maybe we should keep the previous result
too?
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'm not sure about that, because I think if I send a loading
, the previous result is not longer valid? So if we rely on a previous result somewhere we might change this
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'm also not sure it's needed, but we used to do it when setting the loading state in use_discover_histogtam
too, so probably best to keep passing result
for now. It would get rid of this conditional too (and the comment above doesn't apply anymore anyway).
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.
You're both right, let's simplify the code ... done
|
||
// Do not sync the loading state since it's already handled by the saved search | ||
if (fetchStatus !== FetchStatus.LOADING) { | ||
savedSearchHits$.next({ |
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 think there was a good reason why the histogram was sending the loading
status all this time. But I don't remember all the cases about that. Do you mind if we wait for @davismcphee review?
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.
yes, let's wait, from what I've seen, it doesn't hurt keeping it, but on the other hand, I thought it's redundant
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.
As far as I can tell, as long as we're setting the loading state every time infetchAll
, I think this should be ok.
…/use_discover_histogram.ts Co-authored-by: Julia Rechkunova <[email protected]>
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7143[✅] test/functional/apps/discover/group3/config.ts: 50/50 tests passed. |
💚 Build Succeeded
Metrics [docs]Async chunks
History
cc @kertal |
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.
Code changes look good, and it worked well when testing in both data view and ES|QL mode! Just one thing around passing result
I think we should update before merging.
@@ -98,6 +98,8 @@ export function fetchAll( | |||
sendLoadingMsg(dataSubjects.totalHits$, { | |||
result: dataSubjects.totalHits$.getValue().result, | |||
}); | |||
} else { | |||
sendLoadingMsg(dataSubjects.totalHits$); |
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'm also not sure it's needed, but we used to do it when setting the loading state in use_discover_histogtam
too, so probably best to keep passing result
for now. It would get rid of this conditional too (and the comment above doesn't apply anymore anyway).
|
||
// Do not sync the loading state since it's already handled by the saved search | ||
if (fetchStatus !== FetchStatus.LOADING) { | ||
savedSearchHits$.next({ |
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.
As far as I can tell, as long as we're setting the loading state every time infetchAll
, I think this should be ok.
@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.
LGTM, thanks for fixing this!
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/11454245367 |
…nditions (elastic#196114) Fix loading state management in `use_discover_histogram.ts` Moving the loading state for `totalHits$` to the `fetchAll` function, which is executed before the hook. This ensures that the loading state is set at a higher level, preventing a situation where the overall data fetching is in a `loading` state, but the histogram is marked as `complete` while receiving new properties (like a new data view ID) without access to refreshed data views. (cherry picked from commit 722a913)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…ace conditions (#196114) (#197166) # Backport This will backport the following commits from `main` to `8.x`: - [[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)](#196114) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Matthias Wilhelm","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-10-22T06:06:38Z","message":"[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)\n\nFix loading state management in `use_discover_histogram.ts`\r\n\r\nMoving the loading state for `totalHits# Backport This will backport the following commits from `main` to `8.x`: - [[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)](#196114) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT to the `fetchAll` function, which is executed before the hook. This ensures that the loading state is set at a higher level, preventing a situation where the overall data fetching is in a `loading` state, but the histogram is marked as `complete` while receiving new properties (like a new data view ID) without access to refreshed data views.","sha":"722a913c54cd1521d615f9b093d6dd495c65fde9","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Discover","release_note:skip","v9.0.0","Team:DataDiscovery","backport:prev-minor"],"title":"[Discover] Refactor totalHits$ loading state handling to omit race conditions","number":196114,"url":"https://github.com/elastic/kibana/pull/196114","mergeCommit":{"message":"[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)\n\nFix loading state management in `use_discover_histogram.ts`\r\n\r\nMoving the loading state for `totalHits# Backport This will backport the following commits from `main` to `8.x`: - [[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)](#196114) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT to the `fetchAll` function, which is executed before the hook. This ensures that the loading state is set at a higher level, preventing a situation where the overall data fetching is in a `loading` state, but the histogram is marked as `complete` while receiving new properties (like a new data view ID) without access to refreshed data views.","sha":"722a913c54cd1521d615f9b093d6dd495c65fde9"}},"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/196114","number":196114,"mergeCommit":{"message":"[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)\n\nFix loading state management in `use_discover_histogram.ts`\r\n\r\nMoving the loading state for `totalHits# Backport This will backport the following commits from `main` to `8.x`: - [[Discover] Refactor totalHits$ loading state handling to omit race conditions (#196114)](#196114) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT to the `fetchAll` function, which is executed before the hook. This ensures that the loading state is set at a higher level, preventing a situation where the overall data fetching is in a `loading` state, but the histogram is marked as `complete` while receiving new properties (like a new data view ID) without access to refreshed data views.","sha":"722a913c54cd1521d615f9b093d6dd495c65fde9"}}]}] BACKPORT--> Co-authored-by: Matthias Wilhelm <[email protected]>
Fixes #184600
Summary
A simpler approach than #194904, solving the root cause of the flakiness. We had a race condition based on observable messaging of our data state, that led to the following screenshot:
It was happening because the loading state of totalHits$ was set by the histogram in
use_discover_histogram.ts
.By setting the loading state in the
fetchAll
function, which is executed before the hook, the loading state is set on a higher level. This can no longer lead to a state that the overall data fetching is set toloading
, while the histogram is still set tocomplete
while already getting new properties like a new data view id, but not having access to a refreshed list of data views. Overall this seems to be the cleaner approach.[✅] test/functional/apps/discover/group3/config.ts: 25/25 tests passed. kibana-flaky-test-suite-runner#7138
Checklist