We saw a case where the recovery stats reported `recovered_bytes` greater than `length_in_bytes` for one file:

```
GET /_recovery?detailed

200 OK
...
{
  "name": "_buk.fdt",
  "length_in_bytes": 26891307173,
  "reused": false,
  "recovered_in_bytes": 35324928266,
  "recovered_from_snapshot_in_bytes": 8433621093
}
...
```

NB `35324928266 == 26891307173 + 8433621093`

This causes Elasticsearch to compute a negative value for the reserved space on the target node of this recovery, which prevents stats APIs from working. This appears to be caused by a network-level failure which triggers a retry without first cancelling an ongoing download of a different file with the same name from the snapshot repository.

---

### Workaround

Restart the target node to clear these stats.
server/src/main/java/org/elasticsearch/indices/recovery/RecoveryState.java
import java.util.Collection;
import java.util.HashMap;
import java.util.List;
import java.util.Locale;
import java.util.Map;
/**
 * Keeps track of state related to shard recovery.
 */
public class RecoveryState implements ToXContentFragment, Writeable {
    public enum Stage {
        INIT((byte) 0),
        /**
         * recovery of lucene files, either reusing local ones are copying new ones
         */
        INDEX((byte) 1),
        /**
         * potentially running check index
         */
        VERIFY_INDEX((byte) 2),
        /**
         * starting up the engine, replaying the translog
         */
        TRANSLOG((byte) 3),
        /**
         * performing final task after all translog ops have been done
         */
        FINALIZE((byte) 4),
        DONE((byte) 5);
        private static final Stage[] STAGES = new Stage[Stage.values().length];
        static {