-
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] Add internalState loading function preventing data view id change related race conditions #199419
The head ref may contain hidden characters: "discover-unskip-_lens_vis\u00B7ts"
[Discover] Add internalState loading function preventing data view id change related race conditions #199419
Changes from all commits
bf323b8
036538a
7d4e3da
d574963
7726c7d
4cfc4f3
0cb4cf1
4f9d4ab
7f1503e
82ebd2e
fc4ddd2
3f77801
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -110,8 +110,7 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) { | |||
return seriesType; | ||||
} | ||||
|
||||
// FLAKY: https://github.com/elastic/kibana/issues/184600 | ||||
describe.skip('discover lens vis', function () { | ||||
describe('discover lens vis', function () { | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We might need to load data views right after a new one is created and before it gets replaces in the app state/URL: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. there's some really dark magic here, that even when investigating this caused my IDE to freeze, so just before the last meeting of my day, I'm thinking that the cleanup of adhoc data views that were changed because of a spec change, should be triggered later on: kibana/src/plugins/discover/public/application/main/state_management/discover_state.ts Line 430 in 7f1503e
because then the previous data view would still be available, wouldn't do any harm, and be removed after the data fetching was triggered There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. clearly broken here, looking for a simpler solution, so far I couldn't this seems to resolve this issue locally, let's see what flaky test runner says: #199982 |
||||
before(async () => { | ||||
await security.testUser.setRoles(['kibana_admin', 'test_logstash_reader']); | ||||
await esArchiver.loadIfNeeded('test/functional/fixtures/es_archiver/logstash_functional'); | ||||
|
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 wonder if
isDataViewLoading
should be toggled 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.
For me it appears we just use
isDataViewLoading
inkibana/src/plugins/discover/public/application/main/components/layout/discover_documents.tsx
Line 169 in 8545b9c
and
kibana/src/plugins/discover/public/application/main/components/layout/discover_layout.tsx
Lines 104 to 107 in 7369442
We set it to true when a data view is being changes.
With the new
isLoading
prop those components should not be displayed. So I'd say it's not necessary ... one think I wonder, would it make sense to combing all those loading states into one prop? one that can be used to get information about general loading state, data view loading state, data loading state ... just load thinkingThere 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.
Yeah, I was also wondering if we could use
isDataViewLoading
instead of introducing a newisLoading
.Editing a data view might be considered as "loading" its new state.
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 I splitted this work (again):
Hopefully near term solution: #199982
Experimental loading refactoring, moving to one loading state instead of
isDataViewLoading
andisLoading
: #199956