There will always be a very small window after HO get the block address and before sending read to the underlying data service, the chunk got selected by GC, moved the blob, returned to heap chunk selector, select by a new shard and a new blob is written on the same block address. This is very unlikely to happen, but conceptually possible, and once it happens, there will be data mismatch. It can be solved by read verification (cross check the blob_id, shard_id from the key) with the data portion blob header. If the blob is rewritten to other shards, it will report mismatch and we should fail this read and let the gateway to retry. Retry will be successful as it will arrive on a new chunk.
There will always be a very small window after HO get the block address and before sending read to the underlying data service, the chunk got selected by GC, moved the blob, returned to heap chunk selector, select by a new shard and a new blob is written on the same block address. This is very unlikely to happen, but conceptually possible, and once it happens, there will be data mismatch. It can be solved by read verification (cross check the blob_id, shard_id from the key) with the data portion blob header. If the blob is rewritten to other shards, it will report mismatch and we should fail this read and let the gateway to retry. Retry will be successful as it will arrive on a new chunk.