[azure-storage-blob] list_blobs() cannot work with include=metadata

[Juliehzl]

• Package Name: azure-storage-blob
• Package Version: 12.4.0-b1
• Operating System: Windows
• Python Version: 3.7.7

Describe the bug
A clear and concise description of what the bug is.

When listing blobs in a container with metadata information, as description mentioned and track1 behavior, we could add --include=metadata to get such results.

But when I use it in new sdk, I can get the response with metadata information in raw response here as shown below but after deserialization it is skipped and change to None.

b'\xef\xbb\xbf<?xml version="1.0" encoding="utf-8"?>
<EnumerationResults ServiceEndpoint="https://zuhdefault.blob.core.windows.net/" ContainerName="test1">
<MaxResults>2</MaxResults><Blobs>
<Blob><Name>a.txt</Name><VersionId>2020-08-06T03:20:00.9910412Z</VersionId>
<IsCurrentVersion>true</IsCurrentVersion><Properties><Creation-Time>Tue, 14 Jul 2020 07:58:04 GMT</Creation-Time>
<Last-Modified>Thu, 06 Aug 2020 03:20:00 GMT</Last-Modified><Etag>0x8D839B79AAF1A66</Etag>
<Content-Length>1200</Content-Length><Content-Type>text/plain; charset=utf-8</Content-Type><Content-Encoding />
<Content-Language /><Content-CRC64 /><Content-MD5>4edJNByMxQgCm9dVVN4KWQ==</Content-MD5>
<Cache-Control /><Content-Disposition /><BlobType>BlockBlob</BlobType><AccessTier>Hot</AccessTier>
<AccessTierInferred>true</AccessTierInferred><LeaseStatus>unlocked</LeaseStatus><LeaseState>available</LeaseState>
<ServerEncrypted>true</ServerEncrypted></Properties><Metadata><test>1</test></Metadata><OrMetadata /></Blob>
<Blob><Name>ast.md</Name><Properties><Creation-Time>Tue, 14 Jul 2020 07:58:05 GMT</Creation-Time>
<Last-Modified>Tue, 14 Jul 2020 07:58:05 GMT</Last-Modified><Etag>0x8D827CBA3A2B2BC</Etag>
<Content-Length>0</Content-Length><Content-Type>application/octet-stream</Content-Type><Content-Encoding />
<Content-Language /><Content-CRC64 /><Content-MD5>1B2M2Y8AsgTpgAmY7PhCfg==</Content-MD5>
<Cache-Control /><Content-Disposition /><BlobType>BlockBlob</BlobType><AccessTier>Hot</AccessTier>
<AccessTierInferred>true</AccessTierInferred><LeaseStatus>unlocked</LeaseStatus><LeaseState>available</LeaseState>
<ServerEncrypted>true</ServerEncrypted></Properties><Metadata /><OrMetadata /></Blob></Blobs>
<NextMarker>2!72!MDAwMDA5IWZpbGUxLnR4dCEwMDAwMjghOTk5OS0xMi0zMVQyMzo1OTo1OS45OTk5OTk5WiE-</NextMarker>
</EnumerationResults>'

I am guessing it is because Model ListBlobsFlatSegmentResponse doesn't include metadata properties. But I think if we have such behavior to include metadata, we should return response with metadata and it will be fine to align with track1 behavior.

If there is anything misuse, feel free to let me know.

To Reproduce
Steps to reproduce the behavior:

1. list_blobs() with include=metadata

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

[Juliehzl]

Hi @kaerm, it seems @xgithubtriage is not valid name.

[kaerm]

It should be working - there is some weirdness around github and how it displays team handles

[xiafu-msft]

Hi @Juliehzl

I'm not able to reproduce it, the test in this pr is working #13260

[tasherif-msft]

Hi @Juliehzl, it should be working. As you have mentioned our list blobs operation is using ListBlobsFlatSegmentResponse however it does deserialize metadata. It has an attribute segment that gets desarialized. This attribute has a dependency on BlobFlatListSegment class which contains an attribute BlobItermInternal class which contains the metadata attribute.

Please let us know if you need further help. Otherwise we can proceed to close this issue.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!