The identification of the range containing the top-chunk is performed by the shard after committing the split to the config server and after refreshing the local metadata. That logic needs to access the collection data, so it instantiates an AutoGetCollection to lock on the collection. As the local shard version might be updated as a consequence of the metadata refresh, it could no longer match with the shard version sent by the router. In this case, AutoGetCollection would throw a stale config error causing the splitChunk command to fail.

A simple solution to resolve the problem is to anticipate the identification of the range containing the top-chunk before refreshing the local metadata.