[ES|QL] An attempt to resolve flaky statuses of ES|QL history items #200949
Conversation
jughosta
added
release_note:fix
Team:DataDiscovery
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Async chunks
cc @jughosta |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7442[✅] test/functional/apps/discover/esql/config.ts: 100/100 tests passed. |
| const nextClientParserStatus = getStatusFromMessages(nextClientParserMessages); | ||
| addQueriesToCache({ | ||
| queryString: code, | ||
| status: nextClientParserStatus, |
There was a problem hiding this comment.
@stratoula It seems that there is a race condition in setting a status for the new history item.
Wdyt about this approach?
I don't quite understand the dependency of this useEffect on clientParserStatus and what other use cases which might affect it. Also when editor1?.current could be unavailable?
It might be better if code owners take a close look at how this race condition can be avoided .
There was a problem hiding this comment.
Yes I know about this problem Julia and I have it on my list. I agree it is better for us to have a look but unfortunately there is no capacity atm. Here is an issue to track it #201079 but I am not sure when we wil find time to tackle this
There was a problem hiding this comment.
@stratoula Alright, thanks!
Summary
This PR is to resolve a race condition in adding items to ES|QL query history.
From the CI failure: should be an error icon for the first history item but it's a green checkmark.
Checklist