Recovery API reports wrong reused file bytes during snapshot restore

[bleskes]

The snapshot restore procedure copies over all the bytes. The output however is: (note reused_in_bytes == total_in_bytes):

 "index": {
               "size": {
                  "total_in_bytes": 4390745019,
                  "reused_in_bytes": 4390745019,
                  "recovered_in_bytes": 31053339,
                  "percent": "0.7%"
               },
               "files": {
                  "total": 136,
                  "reused": 0,
                  "recovered": 3,
                  "percent": "2.2%"
               },
               "total_time_in_millis": 131455,
               "source_throttle_time_in_millis": 0,
               "target_throttle_time_in_millis": 0

[szroland]

This seems to be a simple typo in org.elasticsearch.indices.recovery.RecoveryState toXContent():

            builder.byteSizeField(Fields.TOTAL_IN_BYTES, Fields.TOTAL, totalBytes());
            builder.byteSizeField(Fields.REUSED_IN_BYTES, Fields.REUSED, totalBytes());

The result of totalBytes() is used for both fields when serializing, instead of calling recoveredBytes() in the second case. The values produced by the latter seem to be tested, so I guess this is just an issue of serization, which may not be explicilty tested.

I guess I could fix this, and maybe add a test, if no one else is working on this.

[clintongormley]

@szroland please do

[szroland]

Well, as expected the code wasn't too hard to fix, but while creating the test, I actually ran into an issue with how the Snapshot Create API is described in the rest API json spec file (or rather how that spec is treated in rest tests) vs. how it is actually mapped in its rest controller, see #11897.

Practically if you use snapshot create in a rest test, it sometimes works and sometimes fails, depending on which HTTP method / path combination is picked by the RestClient from the API spec.

[szroland]

@clintongormley, for now I choose to remove the POST option from the snapshot create API json spec file, which makes it possible to create rest tests that include this API.

I think how that spec file and API should look like can be discussed and implemented in the context of #11897. The test case created here should simply continue to work whatever the outcome of that will be.

Let me know what you think.

[bleskes]

@szroland now that #11928 is taken care of, care to extract the fix for this one and make a PR?

[szroland]

I created the new pull request, see #11965 above