Aerospike Replica.RANDOM giving inconsistent result while migrations are in progress

This is expected behavior during migrations. By default our reads to not resolve duplicates within the cluster but our writes do. So if you were to attempt to use the generation from your inconsistent read and perform a write with it, that write will fail because the generation will not match.

If you want to enforce a read to be the latest the cluster has to offer you will need to use a read policy with the consistencyLevel set to CONSISTENCY_ALL. More details on this can be found in this KB article: