fix(http-server-csharp): align controller argument order

[sophia-ramsey]

This pull request addresses the ordering of controller call arguments in the generated C# code for the HTTP server emitter, ensuring that positional arguments match the order defined in the business interface. It introduces a mapping from canonicalized HTTP operations back to their original source operations, updates the controller and action rendering logic to use this mapping, and adds comprehensive tests to verify the new behavior.

Controller argument ordering and operation source mapping:

• The controller action now aligns positional call arguments with the parameter order from the original business interface operation, rather than the default HTTP parameter order. This ensures that the generated C# controller methods call the business logic with arguments in the expected order. (.chronus/changes/http-server-csharp-controller-parameter-ordering-2026-9-8.md)
• Introduced a new OperationSources context and a canonicalOperationSourceMap in service resolution, which tracks the original source operation for each canonicalized HTTP operation. This mapping is provided throughout the emitter to ensure correct argument ordering. (packages/http-server-csharp/src/context/operation-source-context.ts [1] packages/http-server-csharp/src/service-resolution.ts [2]
• Updated the ControllerAction and Controller components to use the source operation from OperationSources when rendering method call arguments, ensuring correct positional mapping. (packages/http-server-csharp/src/components/controller-action/controller-action.tsx [1] [2] [3] [4] [5]; packages/http-server-csharp/src/components/controllers/controllers.tsx Ff671f60L9R9, [6] [7]

Testing and validation:

• Added and updated tests to verify that controller action call arguments and generated interface methods use the correct parameter order, matching the business interface definition. (packages/http-server-csharp/src/components/controller-action/controller-action.test.tsx [1] packages/http-server-csharp/src/components/controllers/controllers.test.tsx [2]
• Added a test to ensure that the canonical operation to source operation mapping is correctly tracked during service type resolution. (packages/http-server-csharp/src/service-resolution.test.ts packages/http-server-csharp/src/service-resolution.test.tsR113-R135)

Emitter integration:

• Integrated the new OperationSources context into the emitter so that all components have access to the canonical operation source mapping during code generation. (packages/http-server-csharp/src/emitter.tsx [1] [2]

These changes together ensure that the generated C# controllers call business logic methods with arguments in the correct order, improving correctness and maintainability of the generated code.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-server-csharp@11903

commit: bed42b1

[github-actions]

All changed packages have been documented.

• ✅ @typespec/http-server-csharp

Show changes

@typespec/http-server-csharp - fix ✏️

Align positional controller call arguments with the generated business-interface parameter order.

[azure-sdk-automation]

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension

[Copilot]

🟡 Changes recommended

Two moderate findings remain involving test modeling and missing emitter-level regression coverage.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Fixes generated C# controller argument ordering by mapping canonical HTTP operations back to their source operations.

Changes:

• Tracks canonical-to-source operation mappings.
• Generates calls using business-interface parameter order.
• Adds resolution, component, emitter, and changelog tests.

File summaries

File	Summary
packages/http-server-csharp/src/service-resolution.ts	Builds source-operation mappings.
packages/http-server-csharp/src/service-resolution.test.ts	Tests mapping behavior.
packages/http-server-csharp/src/emitter.tsx	Provides mappings through emitter context.
packages/http-server-csharp/src/context/operation-source-context.ts	Defines operation-source context.
packages/http-server-csharp/src/components/controllers/controllers.tsx	Passes source operations to actions.
packages/http-server-csharp/src/components/controllers/controllers.test.tsx	Moderate finding: the test does not correctly model source-operation mapping and expects an invalid call order.
packages/http-server-csharp/src/components/controller-action/controller-action.tsx	Orders generated business calls by source parameters.
packages/http-server-csharp/src/components/controller-action/controller-action.test.tsx	Tests reordered arguments.
.chronus/changes/http-server-csharp-controller-parameter-ordering-2026-9-8.md	Records the bug fix.

Review details

Suppressed comments (1)

packages/http-server-csharp/src/components/controllers/controllers.test.tsx:111

• This test maps canonOp to businessGetPet, but BusinessLogicInterface still renders GetPetAsync from getPet (the expected signature is petId, feature, apiVersion). The expected controller call reverses those first two arguments, so the generated C# would not compile and the test does not model the source-operation mapping used by resolveServiceTypes; use one operation with a deliberately different declaration order or validate the full emitter output.

      <OperationSources.Provider value={new Map([[canonOp, businessGetPet]])}>
        <BusinessLogicInterface type={PetStore} canonicalOps={[canonOp]} />
        {"\n"}
        <Controller type={PetStore} operations={[canonOp]} />
      </OperationSources.Provider>

• Files reviewed: 9/9 changed files
• Comments generated: 1
• Review effort level: Lite

---

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