fix(http-server-csharp): handle void success responses - #11905

This PR fixes C# controller generation in @typespec/http-server-csharp so that operations whose success type is void but also include @error union variants are emitted as bodyless success responses (HTTP 204 No Content), rather than incorrectly generating Ok(result).

Changes:

• Updated success-response analysis to skip @error union variants and prefer 204/no-body when the only success variant is void.
• Wired the controller action generator to pass program into response analysis for proper @error detection.
• Added/updated tests and snapshots to verify the generated controller code for void | @error and value-or-error unions.

• Files reviewed: 4/5 changed files
• Comments generated: 0
• Review effort level: Lite

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

packages/http-server-csharp/src/components/controller-action/controller-action.test.tsx:147

• This test instantiates ServiceOperation<string>, so the operation has no void success variant and getSuccessStatusCode uses the unchanged fallback path; the expectation therefore also passes with the pre-change implementation. Instantiate a value-plus-void union (for example ServiceOperation<string | void>) or add a separate case so the new union handling is actually exercised and the scalar regression is covered.

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

Suppressed comments (5)

packages/http-server-csharp/src/components/controller-action/response-analysis.ts:43

• This returns immediately for a bodyless success model even when another union variant is a value. For NoContentResponse | string (or the reverse order), hasBody becomes false while getSuccessReturnType produces Task<string>, so the generated action discards the value and always returns NoContent(); keep scanning and prefer a body/value success when one exists.

        for (const variant of type.variants.values()) {
          const result = analyzeVariant(variant.type);
          if (result !== undefined) return result;
        }

packages/http-server-csharp/src/components/controller-action/response-analysis.ts:49

• getSuccessReturnType still treats a model named exactly Error as an error (return-type-helpers.ts:26-34), but this branch only calls isErrorModel. For void | Error without an @error decorator, the interface is generated as Task while hasBody is true, so the controller emits var result = await ... against a non-generic Task and fails to compile; apply the same name-convention check here.

        if (isErrorModel(program, type)) return undefined;

packages/http-server-csharp/src/components/controller-action/response-analysis.ts:67

• When every variant is an error, neither hasValueSuccess nor hasVoidSuccess is set, so this falls through to the generic { statusCode: 200, hasBody: true } result below. getSuccessReturnType now returns undefined for the same union, causing a Task business method but controller code that assigns var result and calls Ok(result), which does not compile; handle the no-success case consistently and add an error-only-union regression test.

    if (hasValueSuccess) {
      return { statusCode: 200, hasBody: true };
    }
    if (hasVoidSuccess) {
      return { statusCode: 204, hasBody: false };

packages/http-server-csharp/src/components/controller-action/response-analysis.ts:51

• This filters @error models for union analysis, but direct error return types still take the direct-model path above and are treated as body-bearing successes. Because getSuccessReturnType now returns no success type for a direct @error model, the generated interface is Task while the controller still emits a result assignment/Ok(result); apply the same no-success handling to direct error models and cover that input.

      if (type.kind === "Model") {
        // Skip models with @error decorator or error-range status codes
        if (isErrorModel(program, type)) return undefined;
        const result = analyzeResponseModel(type);
        if (result.statusCode !== undefined && result.statusCode >= 400) return undefined;

packages/http-server-csharp/src/utils/return-type-helpers.ts:29

• This now returns undefined for a direct, body-bearing @error model, while getSuccessStatusCode still treats a direct model as bodyful (response-analysis.ts:18-20). The interface therefore emits Task, but the controller emits var result = await ..., which does not compile for an error-only operation. Keep direct-model response analysis consistent (or explicitly handle/reject error-only operations) and add a regression test.

    if (type.kind === "Model") {
      try {
        if (isErrorModel(program, type)) return undefined;

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