A customer may configure an active/passive pair of repo 3 instances which both refer to the same underlying blobstore(s) as part of a resiliency architecture.
NEXUS-11967 introduced named deletions.index files unique to each "node" in a running HA-C (legacy) cluster of concurrently running nodes. Each instance has a unique node id.
In the new resiliency architecture, this could introduce an issue in an active/passive scenario if the node id of the active and passive nodes differ.
As instance 1 is used, the respective blobstore [NODE-ID]-deletions.index is updated to contain content marked as "to be deleted".
When switching to instance 2, if it has a different node ID, this will prevent it from reading the original instance 1 deletions index file, and as a result will not perform equivalent/expected blobstore compactions against the same blobstore that instance 1 used.
The document at https://help.sonatype.com/repomanager3/planning-your-implementation/backup-and-restore/backup-and-restore-in-amazon-web-services does not mention anything about consistent node ids, where they are stored, how they are generated, the deletions index file itself or what to backup from an instance data directory.
The document at https://help.sonatype.com/repomanager3/planning-your-implementation/resiliency-and-high-availability/single-node-cloud-resilient-deployment-example-using-aws suggests a passive pod will be started from scratch and therefore implicitly suggests it will have a different node id than the active instance.
The document https://help.sonatype.com/repomanager3/planning-your-implementation/backup-and-restore/prepare-a-backup#PrepareaBackup-NodeIDBackup suggests Node ID backup is crucial to normal operation of the product.
Design and document a resilient deletions index model that will mitigate the risk of two nodes that are intended to be identical from operating differently due to not accessing the same deletions history.