Handle Parameter Type Changes in Service Methods

[jorgerangel-msft]

This has occurred at least once in Azure.AI.Translation.Document.

Changing a parameter type in a GAd library is a breaking change:

 public virtual Azure.Response<Azure.AI.Translation.Document.SupportedFileFormats> GetSupportedFormats(Azure.AI.Translation.Document.FileFormatType? type = default(Azure.AI.Translation.Document.FileFormatType?), System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }

to

public virtual Azure.Response<Azure.AI.Translation.Document.SupportedFileFormats> GetSupportedFormats(Azure.AI.Translation.Document.FileFormatType type, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }

We should add back compat support to detect this scenario and avoid generating a breaking change.

[jorgerangel-msft]

Since we can reasonably support both overloads I think we can generate the new one and just EBN the old one (and probably make the changed property required)

If the parameter with the changed type is optional, then we'd end up with ambiguous callsites.

[github-actions]

🎯 Issue Triage

A request to add backward compatibility support in the C# client emitter for detecting parameter type changes (e.g., nullable FileFormatType? to non-nullable FileFormatType) that would constitute breaking changes in GA'd libraries.

Category: Feature Request

Area: emitter:client:csharp

🔍 Analysis

• The issue references a concrete example from Azure.AI.Translation.Document where a method signature changed from accepting a nullable optional parameter (FileFormatType? type = default(...)) to a non-nullable required parameter (FileFormatType type).
• In GA'd SDK libraries, this constitutes a breaking change for callers that previously passed null.
• The C# emitter should detect when a parameter type changes from nullable/optional to non-nullable/required and maintain backward compatibility, either by keeping the nullable signature, emitting a compat overload, or surfacing a diagnostic to prevent the breaking change from being emitted silently.
• Affected component: http-client-csharp / C# client emitter code generation for service method parameters.

📝 Suggested next steps

• Determine the correct backward compat strategy: preserve nullable signature, emit overload, or raise a diagnostic/warning in the emitter.
• Identify where in the C# emitter the method parameter type is resolved, and hook in the compat detection logic.
• Add a test case using the Azure.AI.Translation.Document pattern (nullable → non-nullable) to validate the fix.

Generated by Agentic Triage