-
Notifications
You must be signed in to change notification settings - Fork 25.7k
Description
This happened in
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+multijob-unix-compatibility/os=sles/2661/consoleText
The REPRO line is this, although since it's timing-related it won't reproduce reliably:
./gradlew :x-pack:plugin:ml:qa:native-multi-node-tests:integTestRunner \
-Dtests.seed=C417041F0B398073 \
-Dtests.class=org.elasticsearch.xpack.ml.integration.ForecastIT \
-Dtests.method="testDelete" \
-Dtests.security.manager=true \
-Dtests.locale=ja-JP \
-Dtests.timezone=Asia/Tbilisi \
-Dcompiler.java=10 \
-Druntime.java=8
I think the problem is that we're not refreshing the index after deleting the forecast documents, yet the test is assuming that all documents will be unsearchable when the delete call returns. I think it's good that the contract of the delete forecast endpoint is that you will not find documents related to the forecast if you search for them after the endpoint returns. So that means we need to refresh the index in the delete forecast code. The simplest way should be to add setRefresh(true) to the DBQ request, similar to
Line 103 in 284c45a
| request.setRefresh(true); |