Merge pull request #3964

* [DOC-13712]: Add release note for MB-66434

* [DOC-13712]: Add release note for MB-66434

Author: RayOffiah

modules/release-notes/partials/docs-server-7.6.8-release-note.adoc

@@ -8,8 +8,6 @@ This maintenance release contains fixes to issues.
 == Fixed Issues
 
 
-
-
 === Cluster Manager
 [#table-fixed-issues-768-cluster-manager, cols='10,40,40']
 |===
@@ -21,7 +19,7 @@ This maintenance release contains fixes to issues.
 a|*Metric Rename – Cache Miss Ratio → Get Miss Ratio*
 The _Cache Miss Ratio_ metric name suggested it measured memory or disk caching performance.
 In practical instances, as of version 7.6.2, it was redefined to measure the proportion of read (`get`) operations that fail because the requested key is not present in the bucket at all.
- To eliminate this confusion, the metric has been renamed to *Get Miss Ratio*.
+ To eliminate confusion, the metric has been renamed to *Get Miss Ratio*.
 
 | Issue resolved
 
@@ -122,8 +120,31 @@ The updates involve implementing proper checks for int64 overflow  to properly r
 
 
 
+=== Index Service
+[#table-fixed-issues-768-index-service, cols='10,40,40']
+|===
+|Issue | Description | Resolution
 
+| https://jira.issues.couchbase.com/browse/MB-66434[MB-66434]
+| In certain scenarios where `shard affinity` has been toggled on or off, or a previous rebalance was canceled midway,
+the Alternate Shard IDs for some replicas may be reset.
+During a later rebalance where shard affinity is enabled and `optimise index placement` is turned off,
+the replica repair process assigns a shard to the lost replica based on the Alternate Shard ID of its surviving counterpart.
+The existing replicas whose Alternate Shard IDs were reset are also re-assigned the same Alternate Shard ID.
 
+However, since index movement is turned off (due to `optimise index placement` being off),
+these replicas remain on their original nodes.
+As a result, the same Alternate Shard ID can end up being present on multiple nodes.
+This violates the planning invariant that requires each Alternate Shard ID exists on one node only.
+Violation of this invariant led to a panic during rebalance.
+
+| This complex condition was considered in the later stages of planning,
+to ensure that whenever non-moving indexes are also assigned the Alternate Shard ID,
+they are not to be considered in the planning of moving indexes.
+
+This will prevent the occurrence of panics during a rebalance.
+
+|===