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/index/shard/IndexShard.java
boolean wasActive = active.getAndSet(false);
            if (wasActive) {
                logger.debug("flushing shard on inactive");
                threadPool.executor(ThreadPool.Names.FLUSH).execute(new AbstractRunnable() {
                    @Override
                    public void onFailure(Exception e) {
                        if (state != IndexShardState.CLOSED) {
                            logger.warn("failed to flush shard on inactive", e);
                        }
                    }
                    @Override
                    protected void doRun() {
                        if (flush(new FlushRequest().waitIfOngoing(false).force(false)) == false) {
                            
                            
                            active.set(true);
                        }
                        periodicFlushMetric.inc();
                    }
                });
            }
        }
    }
    public boolean isActive() {
        return active.get();
    }
    public ShardPath shardPath() {
        return path;
    }
    void recoverFromLocalShards(