fix(http-client-csharp): avoid swapping model factory parameter names when previous contract had same-typed params in different order

[JoshLove-msft]

Problem

PR #10464 introduced ModelFactoryProvider.PreservePreviousParameterNames, which positionally renames current factory-method parameters to match the previous contract whenever the method signatures match by name + parameter types. When the previous and current contracts both have two same-typed parameters but in opposite order, this positional rename silently swaps which parameter feeds which constructor field via the name-based lookup in GetCtorArgs.

This is a real correctness regression and a source-breaking change. Concretely, Azure.AI.VoiceLive.VoiceLiveModelFactory.SessionUpdateConversationItemDeleted regenerates as:

public static SessionUpdateConversationItemDeleted SessionUpdateConversationItemDeleted(string itemId0 = default, string eventId0 = default)
{
    return new SessionUpdateConversationItemDeleted(ServerEventType.ConversationItemDeleted, itemId0, additionalBinaryDataProperties: null, eventId0);
}

Note itemId0 is passed to the constructor's eventId field and eventId0 to the itemId field — values silently end up in the wrong properties. Reproduced via the auto-generated Azure SDK PR Azure/azure-sdk-for-net#58632.

Fix

In PreservePreviousParameterNames, skip the rename when applying it would cause previousName to collide with another current parameter's current name. This preserves the legitimate casing/spec-rename use case (e.g. metricname -> metricName) while preventing the swap pathology.

After the fix, the same factory regenerates correctly:

public static SessionUpdateConversationItemDeleted SessionUpdateConversationItemDeleted(string eventId = default, string itemId = default)
{
    return new SessionUpdateConversationItemDeleted(ServerEventType.ConversationItemDeleted, eventId, additionalBinaryDataProperties: null, itemId);
}

Tests

Added BackCompatibility_SwapTypeParamsDoesNotCorrupt regression test covering the case where the previous contract has two same-typed parameters in swapped order. All 1434 Generator + 1312 ClientModel tests pass.

--generated by Copilot

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@10491

commit: cfbbb0a

[github-actions]

No changes needing a change description found.

[JoshLove-msft]

Good question — I considered named arguments but they wouldn't fix this particular bug.

The root issue is that PreservePreviousParameterNames mutates ParameterProvider.Name in place via Update(name: ...) AFTER the method bodies have already been constructed. The mutation propagates to the cached _asVariable/_asArgument expressions that the body holds references to, so any code in the body that references a renamed parameter renders with the new name.

So even if GetCtorArgs produced named ctor arguments, e.g.:

new SessionUpdateConversationItemDeleted(@type, eventId: <P_evt.var>, additionalBinaryDataProperties: null, itemId: <P_itm.var>)

after the swap-rename runs, P_evt.var would be renamed to itemId and P_itm.var to eventId, and the output becomes:

new SessionUpdateConversationItemDeleted(@type, eventId: itemId, additionalBinaryDataProperties: null, itemId: eventId)

— same semantic swap (eventId field gets itemId).

To make named arguments help we'd have to either (a) rebuild the body after the rename, or (b) snapshot the original parameter names at body-build time so the body's references are decoupled from the ParameterProvider identities. Both are bigger changes than the collision guard in this PR. Happy to follow up with the broader refactor in a separate PR if you'd prefer a more structural fix, but the current change is a low-risk targeted guard.

--generated by Copilot