[http-client-csharp] Preserve model factory back-compat parameter optionality when unambiguous

[live1206]

Description

Model-factory back-compat generation does not consistently preserve or safely adapt the previous contract's required/optional parameter boundary when reordered overloads coexist.

The generator currently has two coarse behaviors:

1. A hidden compatibility overload created through BuildBackCompatMethodSignature(..., hideMethod: true) has every DefaultValue removed, making all parameters required (LastContractView - Make Model Factory Method Parameters Required #8650 / Avoid ambiguous backcompat methods #8674).
2. A reordered factory method can retain the current generated method's all-optional defaults instead of selecting the minimum required prefix needed to keep the overload set unambiguous.

The first behavior can break existing calls that omitted trailing optional arguments. The second can leave reordered, fully optional overloads ambiguous. SDK customization must currently choose a safe middle ground manually: require enough leading parameters to disambiguate while retaining optional trailing parameters.

AppService example

Azure SDK for .NET PR Azure/azure-sdk-for-net#62039 retains custom wrappers in:

sdk/websites/Azure.ResourceManager.AppService/src/Customization/AppService/Models/ArmAppServiceModelFactory.ParameterCompatibility.cs

For example, SiteContainerData has reordered factory overloads. The compatibility wrapper requires the identifying leading parameters but preserves the trailing optional parameters:

public static SiteContainerData SiteContainerData(
    ResourceIdentifier id,
    string name,
    ResourceType resourceType,
    SystemData systemData,
    string image,
    string targetPort,
    bool? isMain,
    string startUpCommand = default,
    SiteContainerAuthType? authType = default,
    // additional optional parameters
    string kind = default)

Making every parameter required breaks calls that provide the leading arguments but omit optional trailing arguments. Keeping every parameter optional can make calls ambiguous with the current reordered overload.

CsmPublishingCredentialsPoliciesEntityData demonstrates the fully optional case: removing its custom wrapper regenerates two reordered, fully optional overloads. Calls that omit arguments can be ambiguous, so the SDK currently suppresses one generated overload and supplies a required forwarding overload.

Expected behavior

When generating model-factory compatibility methods, determine the minimum required parameter prefix needed for unambiguous overload resolution while preserving the previous optional trailing parameters wherever possible.

Please add tests covering:

• Reordered model-factory overloads with required leading and optional trailing parameters.
• Reordered fully optional overloads that would otherwise be ambiguous.
• A compatibility overload where only the minimum parameters, rather than every parameter, need to become required.

Related:

• LastContractView - Make Model Factory Method Parameters Required #8650
• Avoid ambiguous backcompat methods #8674
• Correctly Restore Previous Model Factory Method Order #11617
• Clean up management compatibility workarounds Azure/azure-sdk-for-net#62039

​- by copilot

[github-actions]

🎯 Issue Triage

MethodSignatureHelper.BuildBackCompatMethodSignature unconditionally strips all parameter DefaultValues when generating model-factory back-compat overloads, breaking source-compatible call sites that relied on trailing optional parameters from the previous GA API.

Category: Bug
Area: emitter:client:csharp

⚠️ No reproduction provided. A minimal repro would help diagnose this issue.

🔍 Analysis

• Root cause: In BuildBackCompatMethodSignature, all DefaultValues are cleared whenever hideMethod is true (introduced in Avoid ambiguous backcompat methods #8674 to fix LastContractView - Make Model Factory Method Parameters Required #8650). This is overly aggressive — it's only necessary when omitting defaults would create ambiguous overload resolution.
• Impact: SDK consumers who previously called model factories with trailing optional parameters omitted now get compilation errors after regeneration. Workaround requires CodeGenSuppress + handwritten forwarding methods.
• Affected component: MethodSignatureHelper.BuildBackCompatMethodSignature in http-client-csharp
• Related: LastContractView - Make Model Factory Method Parameters Required #8650, Avoid ambiguous backcompat methods #8674, Correctly Restore Previous Model Factory Method Order #11617, Azure/azure-sdk-for-net#62039

📝 Suggested next steps

• In BuildBackCompatMethodSignature, add overload-ambiguity analysis: only remove defaults from parameters that would create an ambiguous call site with the current signature
• If the previous overload has required leading parameters that already distinguish it from the current signature, preserve all trailing optional parameter defaults
• Add model-factory back-compat tests covering a previous signature with required leading parameters and optional trailing parameters

Generated by Agentic Triage

[live1206]

Jorge Rangel (@jorgerangel-msft) Appreciate your help to fix the back compatibility in mgmt, there is one more left.