tsp-naming-collision

Fix TypeSpec Naming Collisions in Java Codegen

Fix parameter and implementation-model names that end with a numeric suffix (e.g. createAgentRequest1) in generated Java client code. This happens when a TypeSpec named model collides with the synthetic body type the Java codegen creates for an operation that spreads that model.

Root Cause

When a TypeSpec route spreads a named model into an operation's parameters (via ...ModelName), the Java codegen creates a synthetic body type to hold the body properties. It names this type {OperationName}Request (PascalCase of the operation name + Request). If a TypeSpec model already has that exact name, the codegen resolves the collision by appending 1.

Example collision:

• TypeSpec model: CreateAgentRequest
• Operation: createAgent spreads ...CreateAgentRequest
• Codegen synthetic body: wants name CreateAgentRequest → collision → CreateAgentRequest1
• Result: parameter createAgentRequest1, implementation class CreateAgentRequest1.java

Why aliases don't collide: TypeSpec alias declarations don't occupy a name in the type namespace, so there is no collision. If the upstream spec used alias CreateAgentRequest = { ... } instead of model CreateAgentRequest { ... }, no fix would be needed.

Preconditions

• You must be in the directory that contains tsp-location.yaml.
• The TypeSpec must already be synced locally into TempTypeSpecFiles/. If not, run tsp-client sync first.
• Identify the client.tsp file inside TempTypeSpecFiles/ (usually under a subdirectory like sdk-agents/). This is the customization file where fixes are applied.

Important: TempTypeSpecFiles is volatile

TempTypeSpecFiles/ is regenerated on every tsp-client sync or tsp-client update. Changes made only in TempTypeSpecFiles/ will be lost. Always apply the same edits to the corresponding client.tsp in a local checkout of Azure/azure-rest-api-specs (if available) so the changes can be committed to a PR.