Document the index corruption bug that gets fixed via Lucene 8.5.1. (#55232)

Using soft deletes on shrunk indices may cause corruption.

Author: jpountz

docs/reference/release-notes/7.0.asciidoc

@@ -9,6 +9,14 @@ Also see <<breaking-changes-7.0,Breaking changes in 7.0>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Indices created in 6.x with <<date,`date`>> and <<date_nanos,`date_nanos`>> fields using formats
 that are incompatible with java.time patterns will cause parsing errors, incorrect date calculations or wrong search results.
 https://github.com/elastic/elasticsearch/pull/52555

docs/reference/release-notes/7.1.asciidoc

@@ -6,6 +6,14 @@ Also see <<breaking-changes-7.1,Breaking changes in 7.1>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Indices created in 6.x with <<date,`date`>> and <<date_nanos,`date_nanos`>> fields using formats
 that are incompatible with java.time patterns will cause parsing errors, incorrect date calculations or wrong search results.
 https://github.com/elastic/elasticsearch/pull/52555

docs/reference/release-notes/7.2.asciidoc

@@ -88,6 +88,14 @@ Also see <<breaking-changes-7.2,Breaking changes in 7.2>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Indices created in 6.x with <<date,`date`>> and <<date_nanos,`date_nanos`>> fields using formats
 that are incompatible with java.time patterns will cause parsing errors, incorrect date calculations or wrong search results.
 https://github.com/elastic/elasticsearch/pull/52555

docs/reference/release-notes/7.3.asciidoc

@@ -142,6 +142,14 @@ Also see <<breaking-changes-7.3,Breaking changes in 7.3>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Indices created in 6.x with <<date,`date`>> and <<date_nanos,`date_nanos`>> fields using formats
 that are incompatible with java.time patterns will cause parsing errors, incorrect date calculations or wrong search results.
 https://github.com/elastic/elasticsearch/pull/52555

docs/reference/release-notes/7.4.asciidoc

@@ -112,6 +112,14 @@ Also see <<breaking-changes-7.4,Breaking changes in 7.4>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Activating the <<search-slow-log, search slow log>> should be avoided in this version.
 Any attempt to log a slow search can throw an AIOOBE due to a bug that
 performs concurrent modifications on a shared byte array.

docs/reference/release-notes/7.5.asciidoc

@@ -94,6 +94,14 @@ Also see <<breaking-changes-7.5,Breaking changes in 7.5>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Stop all {transforms} during a rolling upgrade to 7.5.
 If a {transform} is running during upgrade, the {transform} audit index might disappear.
 (issue: {issue}/49730[#49730])

docs/reference/release-notes/7.6.asciidoc

@@ -155,6 +155,14 @@ Also see <<breaking-changes-7.6,Breaking changes in 7.6>>.
 [float]
 === Known issues
 
+* Applying deletes or updates on an index after it has been shrunk may corrupt
+the index. In order to prevent this issue, it is recommended to stop shrinking
+read-write indices. For read-only indices, it is recommended to force-merge
+indices after shrinking, which significantly reduces the likeliness of this
+corruption in the case that deletes/updates would be applied by mistake. This
+bug is fixed in {es} 7.7 and later versions. More details can be found on the
+https://issues.apache.org/jira/browse/LUCENE-9300[corresponding issue].
+
 * Indices created in 6.x with <<date,`date`>> and <<date_nanos,`date_nanos`>> fields using formats
 that are incompatible with java.time patterns will cause parsing errors, incorrect date calculations or wrong search results.
 https://github.com/elastic/elasticsearch/pull/52555