Azure-cli: The copy properties of "az storage blob list" are not correct

[bingosummer]

When I use az storage blob show, I can get the copy properties of the blob.

    "copy": {
      "completionTime": null,
      "id": "<redacted",
      "progress": "0/3221225984",
      "source": "<redacted>",
      "status": "pending",
      "statusDescription": null
    },

But using az storage blob list, the copy properties are null values.

      "copy": {
        "completionTime": null,
        "id": null,
        "progress": null,
        "source": null,
        "status": null,
        "statusDescription": null
      },

---

Environment summary

interactive script / 2.0.23 / Ubuntu / bash

[tjprescott]

This happens because the list API call does not return these values, but they are part of the "blob properties" object definition. Thus they get deserialized as null. @troydai we could consider a transform for this command to remove this property.

[bingosummer]

Thanks for your quick response, @tjprescott .
According to https://docs.microsoft.com/en-us/rest/api/storageservices/list-blobs, CopyId, CopyStatus, CopySource, CopyProgress, CopyCompletionTime, and CopyStatusDescription appear in version 2012-02-12 and later, when this operation includes the include={copy} parameter.

[tjprescott]

In that case, we could make inclusion option with a flag.

[williexu]

@bingosummer we have an include option. Use the --include arg to specify that you want copy information to be provided by the endpoint. Ex. az storage blob list -c wilxcontainer --include c will give you the information you desire.

@tjprescott our current functionality is by using --include to specify whatever additional information the user may want. For example, az storage blob list -c wilxcontainer --include sc will give both snapshot and copy information. Having a inclusion flag specifically for "copy" would duplicate same function and may necessitate similar flags for the other inclusion options.

It does seem weird to have those null properties present in the output though. We may consider removing those if the user does not specify it? @troydai @tjprescott

[bingosummer]

Thanks @williexu . It makes sense to me to remove those null properties from the output if --include is not specified.

[williexu]

Though minor, removing these properties may be breaking for some users; ex. piping the results from storage blob list and doing a check on the properties returned. It also is reasonable to have similar models for the outputs of any iteration of the list command.
We have decided not to remove the null properties for now, if we get more complaints from users in the future, we will consider this further along the road.
@bingosummer thanks for your input, glad I could help.