[Bug]: C# emitter: non‑200/204 status codes (e.g., 202 Accepted) are ignored — controller always returns Ok(...) / NoContent()

[srushti-learner]

Describe the bug

When an operation in TypeSpec is annotated to return status codes other than 200 or 204 (e.g., 202 Accepted, 201 Created, 4xx/5xx), the generated ASP.NET Core controller method still returns Ok(result) (or NoContent() when the response type is void). This appears to be due to hardcoded logic in the emitter:

// emitter snippet (as seen in generated code path)
const hasResponseValue = response.name !== "void";
const resultString = ${status === 204 ? "NoContent" : "Ok"};
return this.emitter.result.declaration(
operation.name,
code${doc ?${formatComment(doc)}: ""} [${getOperationVerbDecorator(httpOperation)}] [Route("${httpOperation.path}")] ${this.emitter.emitOperationReturnType(operation)} public virtual async Task<IActionResult> ${operationName}(${declParams}) { ${ hasResponseValue ?var result = await ${this.emitter.getContext().resourceName}Impl.${operationName}Async(${getBusinessLogicCallParameters(parameters)});
return ${resultString}(result);:await ${this.emitter.getContext().resourceName}Impl.${operationName}Async(${getBusinessLogicCallParameters(parameters)});
return ${resultString}(); } }
);
Because resultString selects only Ok or NoContent, any other intended status code is effectively lost.
Impact

202 Accepted (typical for long‑running operations) becomes 200 OK.
201 Created (resource creation) becomes 200 OK and no Location header is set.
Other outcome codes (e.g., 301/302, 400, 409, 500) are not represented correctly, undermining API semantics and client behavior.

Reproduction

https://github.com/microsoft/typespec/blob/main/packages/http-server-csharp/src/lib/service.ts
line 874

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[srushti-learner]

// 202 Accepted response for async operations
model AcceptedAsyncOperationResponse {
@statuscode statusCode: 202;
@Body body: AsyncOperationResponse;
}

this generated the controller as

    [HttpDelete]
    [Route("/acr/{acrName}/repositories/{environmentName}/{serviceName}")]
    [ProducesResponseType((int)HttpStatusCode.Accepted, Type = typeof(AsyncOperationResponse))]
    public virtual async Task<IActionResult> DeleteRepository(string acrName, string environmentName, string serviceName, [FromQuery(Name = "force")] bool? force)
    {
        var result = await AcrAdminOperationsImpl.DeleteRepositoryAsync(acrName, environmentName, serviceName, force);
        return Ok(result);
    }

it should have been Accepted(result) here in the response

[aaronmorgulis-slalom]

My team just ran into this same issue while trying to declare an operation which returns a 201 whereas the C# emitter emits a Ok aka 200. Thanks for posting this issue @srushti-learner, the timing is perfect 😁