cancelClone only sends _recvChunkAbort to the recipient after the cloner has entered kCloning, which is set only after _recvChunkStart succeeds. If the cloner is still kNew, it only tears down local state.

The recipient can start the clone before the donor records that success. If _recvChunkStart succeeds on the recipient and the donor then fails to observe the reply (interrupt, stepdown, or a network timeout), the donor stays in kNew and never aborts. The recipient keeps the incoming-migration slot and continues cloning data that will not be committed until its migrate thread fails on its own.

That delay is not a correctness bug: an uncommitted clone never takes ownership of the chunk. However, it does hold up the next inbound migration to that shard and wastes clone work.