[http-client-csharp] MRW context pruning removes required ARM framework type builders

[live1206]

Describe the bug

The C# generator removes required ModelReaderWriterBuildable attributes for ARM framework types represented by SystemObjectModelProvider, while generated serialization code still deserializes those types through the SDK's ModelReaderWriterContext.

This causes ModelReaderWriter.Read<T>(..., Context.Default) to throw at runtime because Context.GetTypeBuilder(typeof(T)) cannot find a builder.

This appears to be a regression from #11288 (89f388c405438d0f1785857da380c0817bffda17). That change introduced ProviderReferenceMapAnalyzer.IsResolvableBuildableType(), whose IsResolvableBuildableProvider() rejects every SystemObjectModelProvider:

private static bool IsResolvableBuildableProvider(TypeProvider provider) =>
    provider is not SystemObjectModelProvider &&
    provider is not ModelProvider { IsExternal: true } &&
    ShouldWriteProvider(provider);

ModelReaderWriterContextDefinition.CollectBuildableTypesFromFrameworkType() now applies this filter before adding the framework type to the context.

Reproduction

Azure SDK full regeneration PR: Azure/azure-sdk-for-net#61331

In sdk/mysql/Azure.ResourceManager.MySql/src/Generated/Models/AzureResourceManagerMySqlContext.cs, regeneration removes:

[ModelReaderWriterBuildable(typeof(ManagedServiceIdentity))]
[ModelReaderWriterBuildable(typeof(ResponseError))]
[ModelReaderWriterBuildable(typeof(SystemData))]

However, the regenerated serialization code still contains six reads using that context:

• ResponseError: 3 calls
  • ArmOperationStatusResourceProvisioningState.Serialization.cs
  • ErrorResponse.Serialization.cs
  • MySqlFlexibleServerBackupAndExportResult.Serialization.cs
• SystemData: 2 calls
  • MySqlFlexibleServerBackupAndExportResult.Serialization.cs
  • MySqlFlexibleServerLogFile.Serialization.cs
• ManagedServiceIdentity: 1 call
  • MySqlFlexibleServerPatch.Serialization.cs

For example:

identity = ModelReaderWriter.Read<ManagedServiceIdentity>(
    data,
    options,
    AzureResourceManagerMySqlContext.Default);

ModelReaderWriter.Read calls context.GetTypeBuilder(returnType), so these paths fail with InvalidOperationException: No ModelReaderWriterTypeBuilder found ....

Expected behavior

Framework types represented by SystemObjectModelProvider should remain eligible for ModelReaderWriterBuildable when their wrapped SystemType implements IPersistableModel<T> or IJsonModel<T> and is referenced by retained serialization code.

Suggested fix

Update the resolvability check so a SystemObjectModelProvider is considered resolvable for MRW context generation when its wrapped SystemType supports MRW. Add regression coverage for a retained generated model whose serialization reads an external/system model through ModelReaderWriter.Read<T>(..., Context.Default).

[github-actions]

🎯 Issue Triage

A regression introduced in #11288 causes the C# generator to incorrectly prune ModelReaderWriterBuildable attributes for ARM framework types (SystemObjectModelProvider), while the generated serialization code still references those types via ModelReaderWriter.Read(..., Context.Default), resulting in a runtime InvalidOperationException.

Category: Bug
Area: emitter:client:csharp

🔍 Analysis

• Root cause: ProviderReferenceMapAnalyzer.IsResolvableBuildableProvider() unconditionally excludes all SystemObjectModelProvider instances, so CollectBuildableTypesFromFrameworkType() no longer registers them in the MRW context. Serialization code that calls ModelReaderWriter.Read<T>(..., Context.Default) for those types then fails at runtime.
• Regression commit: 89f388c405438d0f1785857da380c0817bffda17 (PR Fix C# reference-map accessibility for hidden union types #11288)
• Affected types: ARM framework types such as ManagedServiceIdentity, ResponseError, SystemData — any SystemObjectModelProvider whose wrapped SystemType implements IPersistableModel<T> or IJsonModel<T>.
• Evidence: Azure SDK full regeneration PR azure-sdk-for-net#61331 demonstrates the missing attributes across multiple MySQL ARM models.

📝 Suggested next steps

• Update IsResolvableBuildableProvider() to allow SystemObjectModelProvider when its wrapped SystemType implements IPersistableModel<T> or IJsonModel<T>.
• Add a regression test: a generated model whose serialization reads an external/system model through ModelReaderWriter.Read<T>(..., Context.Default) should retain the corresponding [ModelReaderWriterBuildable(...)] attribute.
• Verify the fix against the Azure SDK regeneration PR.

Generated by Agentic Triage

[live1206]

Closing as not a bug — the reported runtime failure does not actually occur. Detailed analysis below.

What actually happens in MySql

AzureResourceManagerMySqlContext has a hand-written customization partial at sdk/mysql/Azure.ResourceManager.MySql/src/Custom/MySql/Models/AzureResourceManagerMySqlContext.cs that already declares all three attributes:

[ModelReaderWriterBuildable(typeof(ManagedServiceIdentity))]
[ModelReaderWriterBuildable(typeof(ResponseError))]
[ModelReaderWriterBuildable(typeof(SystemData))]
public partial class AzureResourceManagerMySqlContext : ModelReaderWriterContext

ModelReaderWriterContextDefinition.GetCustomizedBuildableTypes() (added in #11288) intentionally skips types already supplied by customization, so they are dropped from the generated partial. Since attributes merge across partial declarations, the compiled class still carries them and Context.Default.GetTypeBuilder(typeof(ManagedServiceIdentity)) resolves normally. The six ModelReaderWriter.Read<T>(..., Context.Default) call sites listed in the original report are unaffected.

So the regeneration diff is a cosmetic dedup, not a lost builder.

Full classification of the regeneration diff

I reviewed every buildable-attribute removal across the 156 context files in Azure/azure-sdk-for-net#61331 (154x ResponseError, plus 11 others). All fall into three benign buckets:

1. Type genuinely unreferenced -> correct pruning. ResponseError in 153 libraries (Advisor, Avs, Billing, ...) appears only in the context file; same for ApiProfile, ProviderExtendedLocation, ProviderResourceType, ZoneMapping in Azure.ResourceManager.Resources.Deployments.
2. Already declared in a custom partial -> dedup. MySql, MongoCluster (SubResource), StandbyPool (WritableSubResource), OracleDatabase (ArmPlan).
3. Referenced only via non-MRW paths. OperationStatusResult in HybridConnectivity and ManagedNetworkFabric is read through DeserializeXxx in customized code; ModelReaderWriter.Read<OperationStatusResult> count is 0 in both.

Decisive check: of the 154 libraries that lost ResponseError, only MySql actually calls ModelReaderWriter.Read<ResponseError> — and MySql is covered by bucket 2.

Counter-evidence that the pruning is precise: ManagedNetworkFabric keeps ResponseError (it is read via MRW) while losing OperationStatusResult (it is not). Its custom partial declares neither, so retention was decided purely on usage — exactly the intended behavior of #11288.

Rejected fix

I prototyped the suggested fix (make SystemObjectModelProvider resolvable when its wrapped SystemType supports MRW) in #11398 and closed it: it would re-add ~154 ResponseError attributes that are correctly pruned today, regressing output quality without fixing any real failure.

Possible follow-up

If we want a guard rather than relying on diff review, the generator could assert that every type reachable from an emitted ModelReaderWriter.Read<T>(..., Context.Default) call is either in the generated buildable set or in GetCustomizedBuildableTypes(), and emit a diagnostic otherwise. Happy to open a separate issue for that if it seems worthwhile.