Metadata Vanishing #2416
Comments
|
Hi @Mojo1 , By "After that metadata is gone", do you mean you cannot see the container's metadata from Microsoft Azure Storage explorer anymore? I'll try to reproduce the issue. Meanwhile, is it possible for your to share Azurite debug log? |
|
|
|
From the debug log, we only see 3 requests:
We don't see any requests related with add/remove/get container metadata. Besides that, from the "Service_ListContainersSegment" request in the debug log, there is no Uri parameter "include=" with "metadata". Per the rest API doc , in this case the container metadata won't be returned. Azurite behavior is aligned with this. |
|
Yes because i don't do such requests and thats the problem So cant show you whats not there. This Log mirrors everything happening between "metadata there" - "metadata gone" So my impresseion is while getting the detailed list of the container the metadate is getting deleted while serializing it - but thats really just a wild guess. Will check that include thing |
|
From your last debug log, there's "Container_SetMetadata" operation, and the metadata is already set to the container. Service_ListContainersSegment None of them will get container metadata. Especially the "Service_ListContainersSegment" not has Uri parameter "include=metadata" , so metadata will not be returned. Besides that, I have checked with storage explorer (version 1.33.1(98)), the metadata set to container can be get by right click on the container and choose properties. So this looks not an Azurite issue, but your client code issue. Besides that, I have also tested with storage explorer, if you choose "Blob Container" node, right click and choose refresh, it will send a "Service_ListContainersSegment" request with Uri |
|
However, I believe there is still an issue. Here is my situation: I create metadata in Storage Explorer. Even if I do not include the &include=metadata parameter, the metadata should remain intact. |
|
Thanks for your reply! However, why you think "the metadata has been deleted." If you do not "include the &include=metadata parameter" in list container, the container metadata on Server still remain, but won't return in the list container result. If "the metadata has been deleted" is true, please give the Azurite debug log from add the metadata, to the request you think metadata should be return but not return. |
|
Here is a new log.
So there has been ONE Put request and a lot of GET requests. Still data changes after GET requests only |
|
Thanks for the new log! It looks list container request without "&include=metadata" will clear the container metadata, the related code is: Azurite/src/blob/handlers/ServiceHandler.ts Line 334 in ef2e312 Seems the above code will not only clear metadate in the return value, but also the metadate of the container on server. We will see how to fix this issue. |
|
I have raised a PR to fix this issue: #2426 |
|
Okay, thanks everybody |
|
Issue has been fixed. Any further investigation required, please feel free to reopen the issue. |
Which service(blob, file, queue, table) does this issue concern?
blob
Which version of the Azurite was used?
3.31
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
Npm and Visual Studio code
What's the Node.js version?
20.14
What problem was encountered?
This is a really curious issue with metadata. As soon as I iterate over blob containers in code metadata vanish.
I don't know if it's a problem with Azurite Emulator or if the java lib is buggy. I tracked it down just to this iteration. No other operations done.
Also opened issue with azure spring boot
microsoft/spring-cloud-azure#1063
Steps to reproduce the issue?
Could be any party involved losing it. Thought I try here for investigation
public Map<String, ConfigType> getConfigTypes() { Map<String, ConfigType> configTypes = new HashMap<>(); PagedIterable<BlobContainerItem> blobContainerItemPages = blobServiceClient.listBlobContainers(); Iterator<PagedResponse<BlobContainerItem>> iterator = blobContainerItemPages.iterableByPage().iterator(); while (iterator.hasNext()) { PagedResponse<BlobContainerItem> blobContainerItems = iterator.next(); processBlobContainerItems(blobContainerItems, configTypes); } return configTypes; } private void processBlobContainerItems(PagedResponse<BlobContainerItem> blobContainerItems, Map<String, ConfigType> configTypes) { for (BlobContainerItem blobContainerItem : blobContainerItems.getValue()) { BlobContainerClient blobContainerClient = blobServiceClient .getBlobContainerClient(blobContainerItem.getName()); List<String> versions = getBlobVersions(blobContainerClient); String latestVersionString = getLatestVersionString(versions); String description = getDescription(blobContainerItem); String title = getTitle(blobContainerItem); ConfigType configType = createConfigType(title, latestVersionString, versions, description); configTypes.put(blobContainerItem.getName(), configType); } }If possible, please provide the debug log using the -d parameter, replacing <pathtodebuglog> with an appropriate path for your OS, or review the instructions for docker containers:
Please be sure to remove any PII or sensitive information before sharing!
The debug log will log raw request headers and bodies, so that we can replay these against Azurite using REST and create tests to validate resolution.
Have you found a mitigation/solution?
The text was updated successfully, but these errors were encountered: