[Copilot]

List-to-Get normalization collapsed singleton GET and pageable LIST operations onto the same REST request-builder signature, causing CS0111 despite their distinct request paths.

• Collision handling: Check stable input names and projected C# signatures before applying List-to-Get normalization. Retain the original List name when REST or public declarations would collide, including generated Async variants.
• Compatibility: Preserve non-colliding overloads and existing explicit, published-API, acronym, and URL naming. Compare generic arguments recursively so IEnumerable<int> and IEnumerable<int?> remain distinct signatures.
• Regression coverage: Cover operation order, explicit-name peers, List/GetAll and async-name collisions, valid overloads, unique declarations, and URI/lookup/initial-page/next-page binding.

GetByResourceGroup  → CreateGetByResourceGroupRequest  → …/singletonTrackedResources/default
ListByResourceGroup → CreateListByResourceGroupRequest → …/singletonTrackedResources

• Fixes [http-client-csharp] List/Get normalization creates duplicate REST request builders #12175

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[pkg-pr-new]

Open in StackBlitz

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

commit: 7beecf7

[Copilot]

🟡 Changes recommended

False collision checks can unnecessarily rename existing APIs for exact-name peers and async-only streaming operations.

2 open findings

• Streaming operations reserve nonexistent synchronous API names · New
• Identifier conversion incorrectly reports public API collisions · New

What changed in this PR

Prevents C# List-to-Get normalization from creating duplicate request builders for distinct operations, addressing #12175.

Changes:

• Checks projected names and parameter signatures before normalization.
• Compares generic parameter types recursively.
• Adds regression coverage for collisions, valid overloads, and request binding.

File	Description
packages/​http-client-csharp/​generator/​Microsoft.TypeSpec.Generator/​src/​Shared/​MethodSignatureHelper.cs	Recursively compares generic arguments.
packages/​http-client-csharp/​generator/​Microsoft.TypeSpec.Generator.ClientModel/​test/​Providers/​ClientProviders/​ClientProviderTests.cs	Tests naming collisions, overloads, and request binding.
packages/​http-client-csharp/​generator/​Microsoft.TypeSpec.Generator.ClientModel/​src/​Providers/​ClientProvider.cs	Adds collision-aware List normalization.

🧠 Review effort: Balanced

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Public sync/async comparisons and initial-versus-next-page builder checks still miss collisions that produce duplicate C# declarations.

2 open issues

• Detect initial-request and next-link name collisions · New
• Detect cross-variant generated overload collisions · New

2 resolved since last review

• Compare final emitted signatures after parameter reordering
• Detect collisions using filtered next-link signatures

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Compatibility-preserved parameter ordering can still produce duplicate REST request builders despite the new collision checks.

1 open issue

• Prevent builder overload collisions from compatibility-preserved parameter orde… · New

2 resolved since last review

• Detect cross-variant generated overload collisions
• Detect initial-request and next-link name collisions

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Compatibility ordering still uses the pre-normalized name during public signature checks, allowing duplicate async declarations after renaming.

1 open issue

• Use proposed operation name for compatibility lookup · New

1 resolved since last review

• Prevent builder overload collisions from compatibility-preserved parameter orde…

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Compatibility-sensitive naming changes warrant human validation of downstream API stability, and the signature-projection performance concern remains unresolved.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Skip disjoint peers before rebuilding operation parameters

packages/​http-client-csharp/​generator/​Microsoft.TypeSpec.Generator.ClientModel/​src/​Providers/​ClientProvider.cs:429

Skip peers with disjoint emitted names before projecting their parameters: CleanOperationNames invokes this path twice per List operation (ClientProvider.cs:220–224), but both protocol variants and convenience parameters are rebuilt for every unrelated peer. This adds quadratic parameter construction and repeated compatibility lookups to client creation even when no names can collide; intersect GetEmittedMethodNames first and return early.

1 resolved since last review

• Use proposed operation name for compatibility lookup

_{Review effort: Balanced}

[Jorge Rangel (jorgerangel-msft)]

Copilot overall, the changes are way too complicated. Ideally, we simplify the PR and fix the problem we are trying to solve. If we can target the changes to simply avoid collisions based on method names, that may reduce a lot of the complexity we are adding.

[Copilot]

Copilot overall, the changes are way too complicated. Ideally, we simplify the PR and fix the problem we are trying to solve. If we can target the changes to simply avoid collisions based on method n...

Simplified the collision handling to use emitted method names rather than parameter signatures, removed the projection machinery, and restored the existing REST/protocol parameter-building paths. Commit: 7beecf78.

[Copilot]

🟡 Changes recommended

Name-only collision checks rename valid existing overloads, breaking generated client APIs despite distinct parameter signatures.

1 open issue

• Preserve valid overload names during list normalization · New

_{Review effort: Balanced}