From eded5bc4f3776c9841a4995972f29c6c07d81c46 Mon Sep 17 00:00:00 2001 From: Nik Everett Date: Tue, 23 Jan 2018 13:35:23 -0500 Subject: [PATCH] Reindex: Wait for deletion in test The test failure tracked by #28053 occurs because we fail to get the failure response from the reindex on the first try and on our second try the delete index API call that was supposed to trigger the failure actually deletes the index during document creation. This causes the test to fail catastrophically. This PR attempts to wait for the failure to finish before the test moves on to the second attempt. The failure doesn't reproduce locally for me so I can't be sure that this helps at all with the failure, but it certainly feels like it should help some. Here is hoping this prevents similar failures in the future. --- .../elasticsearch/index/reindex/ReindexFailureTests.java | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/modules/reindex/src/test/java/org/elasticsearch/index/reindex/ReindexFailureTests.java b/modules/reindex/src/test/java/org/elasticsearch/index/reindex/ReindexFailureTests.java index f101b125382..f5e234f66ca 100644 --- a/modules/reindex/src/test/java/org/elasticsearch/index/reindex/ReindexFailureTests.java +++ b/modules/reindex/src/test/java/org/elasticsearch/index/reindex/ReindexFailureTests.java @@ -107,6 +107,14 @@ public class ReindexFailureTests extends ReindexTestCase { response.get(); logger.info("Didn't trigger a reindex failure on the {} attempt", attempt); attempt++; + /* + * In the past we've seen the delete of the source index + * actually take effect *during* the `indexDocs` call in + * the next step. This breaks things pretty disasterously + * so we *try* and wait for the delete to be fully + * complete here. + */ + assertBusy(() -> assertFalse(client().admin().indices().prepareExists("source").get().isExists())); } catch (ExecutionException e) { logger.info("Triggered a reindex failure on the {} attempt: {}", attempt, e.getMessage()); assertThat(e.getMessage(),