Storage `BlobMetadata` type doesn't appear to actually contain metadata.

[LarryOsterman]

Bug Title

BlobMetadata doesn't seem to include metadata.

Crate Name

azure_storage_blob

Crate Version

0.4.0

Description

The BlobMetadata definition looks like:

/// The blob metadata.
#[derive(Clone, Default, Deserialize, SafeDebug, Serialize)]
#[non_exhaustive]
pub struct BlobMetadata {
/// Whether the blob metadata is encrypted.
#[serde(rename = "@Encrypted", skip_serializing_if = "Option::is_none")]
pub encrypted: Option,
}

But I don't see a HashMap which would actually contain the metadata associated with the blob.

Am I holding it wrong?

Steps to Reproduce

Attempt to write code that refreences the metadata in a blob.

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[vincenttran-msft]

Note: This model is coming back in i.e. list_containers inside of BlobItemInternal
This seems to be a bug in the TypeSpec authoring. TypeSpec model here:

/** The blob metadata. */
// TODO: check if this needs an unwrapped decorator
#suppress "@azure-tools/typespec-autorest/unsupported-param-type" "Existing API"
#suppress "@azure-tools/typespec-azure-core/bad-record-type" "Existing API"
model BlobMetadata is Record<string> {
  /** Whether the blob metadata is encrypted. */
  @Xml.attribute
  @Xml.name("Encrypted")
  encrypted?: string;
}

I think this must have been a mistranslation from the swagger of some sort, but either way this really should return the metadata.

However, the mechanism for creating the response metadata will have to be different than, for example, how metadata comes back in get_blob_properties.

In a HEAD request, this is how the metadata comes back:

"x-ms-meta-updated": "values",

Where key is updated and value is values. This properly gets represented as MetadataHeaders in TypeSpec, and surfaces in the code as a HashMap<String, String>

In contrast, for list_blobs, the metadata that will be returned in BlobItemInternal comes back in the XML in this format:

	<Metadata>
				<initial>metadata</initial>
			</Metadata>

Where key is initial and value is metadata.

[vincenttran-msft]

The affected APIs in generated code are list_blob_flat_segment and list_blob_hierarchy_segment (but we do not use the hierarchy one at the moment).

These models both return BlobFlatListSegment and BlobHierarchyListSegment respectively, and both contain a:
pub blob_items: Vec<BlobItemInternal>

Within the BlobItemInternal, is the affected model, BlobMetadata

In short, the only affected API for us right now is our handwritten list_blobs which utilizes list_blob_flat_segment generated API.

[jhendrixMSFT]

I think there are two issues here.

The HashMap<String, String> for the metadata key/values is missing. This is likely a tsp authoring issue.

A custom serde impl will be needed to correctly handle this.

I'm looking into both.

[jhendrixMSFT]

The current authoring makes use of the "additional properties" pattern which isn't yet implemented in the emitter (https://github.com/Azure/typespec-rust/issues/4). For context, additional properties means that the model contains zero or more unnamed key/value pairs. The key type is always string, and in this case, the value type is also string.

Unfortunately, there's no way in the tsp to specify the field name (this is also true in OpenAPI). In Go, it's AdditionalProperties. So, for Rust, it would be additional_properties (assuming we follow suit). Neither are very descriptive for this case.

It's tempting to want to change the authoring as follows.

model BlobMetadata {
  /** Whether the blob metadata is encrypted. */
  @Xml.attribute
  @Xml.name("Encrypted")
  encrypted?: string;

  /** the metadata key/value pairs */
  values: Record<string>;
}

This way we can control the name and emit doc comments. However, I don't think that this is really a general-purpose solution; plus, it doesn't match the XML schema.

So, I think the authoring needs to remain as-is and we come up with a better name than additional_properties or we just live with it.

CC @heaths