[TCGC] @@hierarchyBuilding drops properties that were inherited from the original base but not present in the new base

[ArcturusZhang]

Description

When using @@hierarchyBuilding to change a model's base type to a different model that doesn't contain all the same properties as the original base, properties inherited from the original base are silently dropped from the model instead of being promoted to the model's own properties.

This causes generated SDK code to lose properties that were previously available via inheritance, breaking the API surface.

Repro

Consider a spec like (simplified from Azure Compute):

model UpdateResourceDefinition {
  @visibility(Lifecycle.Read) id?: string;
  @visibility(Lifecycle.Read) name?: string;
  @visibility(Lifecycle.Read) type?: string;
  tags?: Record<string>;
}

model GalleryUpdate extends UpdateResourceDefinition {
  properties?: GalleryProperties;
  identity?: GalleryIdentity;
}

In client.tsp:

#suppress "@azure-tools/typespec-azure-core/no-legacy-usage" "Preserve previous base type"
@@Azure.ClientGenerator.Core.Legacy.hierarchyBuilding(GalleryUpdate,
  Azure.ResourceManager.Foundations.ProxyResource,
  "csharp"
);

Expected behavior

TCGC should output GalleryUpdate with:

• baseModel: ProxyResource
• properties: [properties, identity, tags] — the tags property should be promoted from the dropped UpdateResourceDefinition base because ProxyResource does not define it.

(id, name, type are correctly omitted because ProxyResource provides them.)

Actual behavior

tspCodeModel.json shows:

{
  "name": "GalleryUpdate",
  "baseModel": { "$ref": "<ProxyResource>" },
  "properties": [
    { "name": "properties", ... },
    { "name": "identity", ... }
  ]
}

The tags property is missing entirely — it was on the original base (UpdateResourceDefinition) but is not on the new base (ProxyResource), and TCGC drops it instead of promoting it to GalleryUpdate.

Impact

In Azure SDK for .NET Compute migration (Azure/azure-sdk-for-net#58139):

• Pre-existing baseline: public class GalleryPatch : ResourceData with public IDictionary<string, string> Tags { get; } (inherited from base).
• After applying @@hierarchyBuilding(GalleryUpdate, ProxyResource, "csharp") to fix the base type, Tags is missing from generated code, breaking ApiCompat with MembersMustExist: Member 'Tags.get()' does not exist.

This affects 9 Gallery patch models in Compute: GalleryPatch, GalleryImagePatch, GalleryImageVersionPatch, GalleryApplicationPatch, GalleryApplicationVersionPatch, GalleryScriptPatch, GalleryScriptVersionPatch, GalleryInVmAccessControlProfilePatch, GalleryInVmAccessControlProfileVersionPatch.

Workaround

Add custom partial class code to re-introduce the missing properties — but this is fragile and duplicates the spec.

Environment

• TCGC version: latest (as of @azure-typespec/http-client-csharp-mgmt emitter package shipped with azure-sdk-for-net main)
• Reproducible with the Compute spec at azure-rest-api-specs commit bf19852c9f6 on branch compute/add-csharp-client-customizations (ArcturusZhang fork).

[ArcturusZhang]

Reproduction confirmed in real spec

Tested with Azure Compute spec (commit bf19852c9f635ba5c148c296f5ff00ff1de34158 on ArcturusZhang/azure-rest-api-specs:compute/add-csharp-client-customizations fork).

Spec setup

models.tsp:

model UpdateResourceDefinition {
  @visibility(Lifecycle.Read) id?: string;
  @visibility(Lifecycle.Read) name?: string;
  @visibility(Lifecycle.Read) type?: string;
  #suppress "@azure-tools/typespec-azure-resource-manager/arm-no-record" "For backward compatibility"
  tags?: Record<string>;  // No @visibility - visible in all lifecycles
}

#suppress "@azure-tools/typespec-azure-core/composition-over-inheritance" "For backward compatibility"
model GalleryUpdate extends UpdateResourceDefinition {
  #suppress "@azure-tools/typespec-azure-core/no-legacy-usage" "Backward compatibility"
  @Azure.ClientGenerator.Core.Legacy.flattenProperty
  properties?: GalleryProperties;
  identity?: GalleryIdentity;
}

client.tsp:

using Azure.ClientGenerator.Core.Legacy;

#suppress "@azure-tools/typespec-azure-core/no-legacy-usage" "Preserve previous base type"
@@Azure.ClientGenerator.Core.Legacy.hierarchyBuilding(ComputeGallery.GalleryUpdate,
  Azure.ResourceManager.Foundations.ProxyResource,
  "csharp"
);

Emitter

@azure-typespec/http-client-csharp-mgmt (from azure-sdk-for-net main).

Actual output (tspCodeModel.json)

{
  "name": "GalleryUpdate",
  "namespace": "Azure.ResourceManager.Compute",
  "crossLanguageDefinitionId": "ComputeGallery.GalleryUpdate",
  "usage": "Input,Json",
  "baseModel": { "$ref": "<ProxyResource>" },
  "properties": [
    { "name": "properties", ... },
    { "name": "identity", ... }
    // tags is MISSING - it was inherited from UpdateResourceDefinition (the original base)
    // and is NOT present on ProxyResource (the new base), so it should have been promoted
  ]
}

Expected

tags should appear in GalleryUpdate.properties because:

1. It existed on the original base UpdateResourceDefinition
2. The new base ProxyResource does not provide tags (ProxyResource has only id/name/type/systemData)
3. The Input lifecycle (which GalleryUpdate uses) does not exclude tags via visibility

Notes

• I understand TCGC unit tests did not reproduce this — please consider whether the failure mode is specific to a model whose original base contains both @visibility(Lifecycle.Read)-restricted and unrestricted properties, since that's the case here. Maybe the property visibility filtering happens before/around hierarchyBuilding and accidentally drops everything.
• It is also possible the bug is in @azure-typespec/http-client-csharp-mgmt's consumption of TCGC output rather than TCGC itself — if so, please redirect this issue.
• Workaround: replace @@hierarchyBuilding with @@alternateType + a C#-only model that explicitly spreads ...OmitProperties<Original, "id" | "name" | "type"> to keep all original properties (including tags).

[ArcturusZhang]

Bug location confirmed: TCGC, not the emitter

Inspected the upstream emitter (@typespec/http-client-csharp/dist/emitter/src/lib/type-converter.js lines 138-151):

const properties = [];
for (const property of modelType.properties) {
    const ourProperty = diagnostics.pipe(fromSdkModelProperty(sdkContext, property, modelType));
    if (ourProperty) {
        properties.push(ourProperty);
    }
}
...
inputModelType.baseModel = modelType.baseModel
    ? diagnostics.pipe(fromSdkType(sdkContext, modelType.baseModel))
    : undefined;
inputModelType.properties = properties;

It is a direct pass-through of modelType.properties from TCGC to the InputModelType. No filtering, dropping, or transformation. Therefore the missing tags property is missing from SdkModelType.properties itself — this is a TCGC bug.

Likely test gap

If TCGC unit tests do not reproduce, it may be because the failing model has these specific traits combined:

1. The original base type (UpdateResourceDefinition) defines a mix of properties — some with @visibility(Lifecycle.Read) (id, name, type) and some without (tags)
2. The derived model (GalleryUpdate) is used in an Input context (a PATCH body)
3. The original base type has no further base — it is a root model

Maybe the visibility filter, which correctly removes the Read-only id/name/type for Input usage, also accidentally drops tags when reparenting via hierarchyBuilding (e.g. by replacing the whole inherited property set with what the new base provides instead of merging).

Could you check whether your unit tests have a model whose original base has both visibility-restricted and unrestricted properties? That seems to be the trigger.