# \_flush/synced command shows failures after being clean - indexing stopped **URL:** \ **Category:** Elasticsearch\ **Created:** [June 4, 2021, 9:12am UTC](https://discuss.elastic.co/t/flush-synced-command-shows-failures-after-being-clean-indexing-stopped/274964 "2021-06-04T09:12:42Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![kredfern](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kredfern](https://discuss.elastic.co/u/kredfern)\ **Post date:** [June 4, 2021, 9:12am UTC](https://discuss.elastic.co/t/flush-synced-command-shows-failures-after-being-clean-indexing-stopped/274964/1 "2021-06-04T09:12:42Z")
Just wondering if the following behavior can be explained so that we have confidence to continue the rolling restart procedure. We are using v7.4 cluster. > **[Full-cluster restart and rolling restart | Elasticsearch Guide \[7.4\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/7.4/restart-cluster.html)** We have stopped all indexing into the cluster before these steps are taken. Step 2 talks about issuing a \_flush/synced command until no failures are seen. "When you perform a synced flush, check the response to make sure there are no failures. Synced flush operations that fail due to pending indexing operations are listed in the response body, although the request itself still returns a 200 OK status. If there are failures, reissue the request." We do this and get a situation when there are no failures and then reissue a synced flush 10s later and start seeing failures again? Is this OK, expected? Can we have confidence to continue the rolling restart process? "\_flush/synced?pretty" Thu 3 Jun 11:30:25 UTC 2021 { "\_shards" : { "total" : 16708, "successful" : 16678, "failed" : 30 }, .. .. Then having a situation when there are no failed and issuing the command again ....(with more detail) \_flush/synced?pretty" | grep -i -B 1 -A 15 failures Thu 3 Jun 12:09:52 UTC 2021 "failed" : 1, "failures" : [ { "shard" : 2, "reason" : "pending operations", "routing" : { "state" : "STARTED", "primary" : true, "node" : "4SO4lMH-TMik7l1rNBhBdA", "relocating\_node" : null, "shard" : 2, "index" : "7\_0df0304d\_01b6\_4cba\_825f\_58f36bbfdb2f-000001", "allocation\_id" : { "id" : "gCT0LSolRai7XguuBMLvZw" } } Is there anyway to know what these pending operations are? Should we care after a single situation with no failures? Obviously, something else is going on behind the scenes. Any other debug/options to help shed light on what is going on? Looking into elastic code a little more, I see code snippets like the following .. **if** (indexWriter.hasUncommittedChanges()) { logger.trace( **"can't sync commit [{}]. have pending changes"** , syncId); **return** SyncedFlushResult.PENDING\_OPERATIONS; [https://lucene.apache.org/core/7\_7\_3/core/org/apache/lucene/index/IndexWriter.html#hasUncommittedChanges--](https://lucene.apache.org/core/7_7_3/core/org/apache/lucene/index/IndexWriter.html#hasUncommittedChanges--) " \* Returns true if there may be changes that have not been committed. There are cases where this may return true when there are no actual "real" changes to the index, for example if you've deleted by Term or Query but that Term or Query does not match any documents. Also, if a merge kicked off as a result of flushing a new segment during [`commit()`](https://lucene.apache.org/core/7_7_3/core/org/apache/lucene/index/IndexWriter.html#commit--), or a concurrent merged finished, this method may return true right after you had just called [`commit()`](https://lucene.apache.org/core/7_7_3/core/org/apache/lucene/index/IndexWriter.html#commit--)." ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [June 8, 2021, 3:53am UTC](https://discuss.elastic.co/t/flush-synced-command-shows-failures-after-being-clean-indexing-stopped/274964/2 "2021-06-08T03:53:44Z")
Welcome to our community! 😃 > [@kredfern](#): > > We do this and get a situation when there are no failures and then reissue a synced flush 10s later and start seeing failures again? Is there indexing in that time? > [@kredfern](#): > > We are using v7.4 cluster. Please be aware that 7.4 is now [EOL](https://www.elastic.co/support/eol), you should upgrade to 7.13. ---
**Author:** ![kredfern](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kredfern](https://discuss.elastic.co/u/kredfern)\ **Post date:** [June 8, 2021, 8:37am UTC](https://discuss.elastic.co/t/flush-synced-command-shows-failures-after-being-clean-indexing-stopped/274964/3 "2021-06-08T08:37:17Z")
Definitely no indexing was happening at the time when the \_flush/synced commands were being run. Yes, realize that we are EOL here and planning to upgrade soon. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2021, 8:37am UTC](https://discuss.elastic.co/t/flush-synced-command-shows-failures-after-being-clean-indexing-stopped/274964/4 "2021-07-06T08:37:25Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.