This is a bug in checkpoint synchronization, but not a blocker for 1.8 release.
This issue happens in the following scenario:
1) Set up the 1.7.x cluster and add a very small number of items (e.g., 100K items) into the cluster. At this time, each active vbucket has only one checkpoint with ID 1
2) Shut down the 1.7.x cluster and upgrade it to 1.8 and restart the cluster
3) During the warmup, each vbucket is loaded from disk and its open checkpoint id is updated from vbucket_state table in disk. In this case, each active vbucket open checkpoint still has an id 1, but won't have any items in the open checkpoint.
4) Add a brand-new 1.8 node into the cluster and rebalance.
5) Some active vbuckets are taken over to this new node. However, this does not require backfill operations on the existing nodes because they have the open checkpoint id 1 for all active vbuckets and the new node starts with the open checkpoint 1 as well.
6) After rebalance, the new node has 0 items on its active vbuckets.
The above scenario is the corner case because we tested it with the 1.7.x cluster that has been running for a very short time that is less than a new checkpoint creation interval 10 minutes. Therefore, it is not likely to happen in our customers' clusters that have a long running 1.7.x membase and large open checkpoint ids for active vbuckets.