[Bug]: http-server-csharp: Some generated model files have a generic, numbered name

[abatishchev]

Describe the bug

Supposedly, this model represents something like an operation result:

// Generated by @typespec/http-server-csharp
// <auto-generated />
#nullable enable

using System;
using System.Collections.Generic;
using System.Text.Json;
using System.Text.Json.Serialization;
using TypeSpec.Helpers;
using TypeSpec.Helpers.JsonConverters;

namespace Microsoft.MyRpNamespace;

public partial class Model10
{
    /// <summary>
    /// The Location header contains the URL where the status of the long running operation can be checked.
    /// </summary>
    [JsonPropertyName("location")]
    public string Location { get; set; }

    /// <summary>
    /// The Retry-After header can indicate how long the client should wait before polling the operation status.
    /// </summary>
    [JsonPropertyName("retryAfter")]
    public int? RetryAfter { get; set; }
}

But:

• File name: Model13.cs
• Class name: Model13

Reproduction

1. Use an ARM RP typespec
2. Add the following to tspconfig.yaml

emit:
  - "@typespec/http-server-csharp"
options:
  "@typespec/http-server-csharp":
    emitter-output-dir: "{project-root}/generated/{emitter-name}"
    output-type: all
    emit-mocks: none
    overwrite: true

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.

[github-actions]

🎯 Issue Triage

The @typespec/http-server-csharp emitter generates some model files with generic numbered names (e.g., Model13.cs) instead of meaningful names derived from the TypeSpec model definitions, even when the model has identifiable properties.

Category: Bug
Area: emitter:service:csharp

⚠️ No reproduction provided. The steps reference an ARM RP TypeSpec spec but don't include a minimal TypeSpec snippet that triggers the issue — a minimal repro would help diagnose the root cause.

🔍 Analysis

• The emitter falls back to auto-generated numbered names (Model10, Model13) for certain anonymous or inline model types that don't have an explicit TypeSpec name.
• The mismatch between the class name shown in the code comment (Model10) and the actual file/class name (Model13) suggests either a numbering inconsistency or that the displayed code is from a different run.
• The affected model appears to be a response envelope type containing Location and RetryAfter headers, which is a common Azure LRO (Long Running Operation) pattern — likely an anonymous/synthetic type generated by the @azure-tools/typespec-azure-core or @typespec/http library.
• Root cause is likely that the emitter doesn't derive a semantic name for anonymous/synthesized models from their usage context (e.g., the operation name or response type).

📝 Suggested next steps

• Provide a minimal TypeSpec snippet (ideally without the full ARM RP spec) that reproduces the numbered model name.
• Investigate how the emitter assigns names to anonymous model types and whether the operation context can be used to derive a meaningful name.
• Check if similar naming issues exist for other synthesized types in the ARM pattern.

Generated by Agentic Triage