Make EsqlSpecTestCase more resilient and re-enable some performance updates #136781
Conversation
This reverts commit 207787a.
…lizing index creation (elastic#134090)" (elastic#134511) This reverts commit d915090.
elasticsearchmachine
added
the
needs:triage
craigtaverner
added
>non-issue
Team:Analytics
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
| } | ||
| } | ||
|
|
||
| private static final Protected INGEST = new Protected(); |
There was a problem hiding this comment.
In the Views PR we use a separate VIEWS protector, semi-decoupling views from index creation. We could break the index parts into finer grained stuff too, but I see risks with that.
|
Sadly, we already see failures from the parallel data loading. I think the changes to EsqlSpecTestCase do give slightly better error messages, but not enough to determine the underlying cause. I'll do some local investigation to see if I can figure this out, otherwise revert that particular commit, and we deal with parallel data loading separately. |
| }); | ||
| try { | ||
| Response remote = remoteResponse.get(); | ||
| Response local = localResponse.get(); |
There was a problem hiding this comment.
NIT: you could use PlainActionFuture instead of anonymous listeners implementations here.
3 participants
Some recent test performance updates flushed out test fragility due to non-thread safety and other concurrency issues with test setup. This PR adds some more resiliency and brings back the performance work. The actual implementation here was extracted from the Views PR at #134995, which, due to early issues in view creation/deleting during test setup was reliably exposing the same errors seen in #134736.
Checklist:
Fixes #134890