[Bug]: @friendlyName on enum is skipped when enum is first referenced inside a template` #12345

Activity

1. dalbrx-nitrobox

   added

   bugSomething isn't workingSomething isn't working

   on Oct 22, 2026
2. microsoft-github-policy-service

   added

   needs-area

   on Oct 22, 2026
3. github-actions commented on Oct 22, 2026

   

   github-actionsBot

   on Oct 22, 2026 – with GitHub Actions

   Contributor

   More actions

   🎯 Issue Triage

   TypeSpec 1.17.0 can skip decorators on an enum when its first resolution occurs through a templated model property. This prevents @friendlyName metadata from reaching emitters and changes the generated OpenAPI schema name.

   Category: Bug

   Area: compiler:core

   🔗 [Playground Reproduction]((typespec.io/redacted)

   📋 Reproduction code

   import "@typespec/http";
   import "@typespec/openapi3";
   using TypeSpec.Http;
   namespace Example.Models;
   
   @friendlyName("AggregationType")
   enum AggregationType {
     SUM,
     COUNT,
   }
   
   model Query<T> {
     aggregationType: AggregationType;
     field: T;
   }
   
   op statistics(...Query<string>): void;

   🔍 Analysis

   The behavior is most consistent with compiler checker state leaking template-declaration context while resolving the concrete enum. The enum then misses decorator evaluation, and @typespec/openapi3 falls back to the fully qualified name. The alias workaround changes resolution order and supports this diagnosis. The checker changes in #9588 are relevant to investigate, but duplicate searches found no issue describing this same regression.

   📝 Suggested next steps

   • Add a compiler regression test covering first resolution of a decorated enum from a template declaration.
   • Verify other enum decorators are evaluated in the same path.
   • Bisect or inspect the checker changes associated with [compiler] Refactor checker to use context, fixing template decorator bugs #9588.

   Generated by Agentic Triage
4. github-actions

   added

   compiler:coreIssues for @typespec/compilerIssues for @typespec/compiler

   on Oct 22, 2026
5. microsoft-github-policy-service

   removed

   needs-area

   on Oct 22, 2026
6. timotheeguerin commented on Oct 22, 2026

   

   Timothee Guerin (timotheeguerin)

   on Oct 22, 2026

   Member

   More actions

   I think this is an unexpected behavior of friendlyName. That decorator was uniquely meant to be used on template to give each instance a name https://typespec.io/docs/standard-library/built-in-decorators/#@friendlyName.

   What is your goal here to have all models defined in Examples.Models to be flattened to the root of the service? A better solution might be an option in openapi3 emitter to toggle this scoping
7. dalbrx-nitrobox commented on Oct 22, 2026

   

   dalbrx-nitrobox

   on Oct 22, 2026

   Author

   More actions

   Thanks, that clarification about the intended use of @friendlyName makes sense.

   Our goal is not necessarily to flatten every model in Example.Models. These are public models provided by a TypeSpec library, and we want to preserve their existing OpenAPI component names for compatibility. An OpenAPI emitter option controlling namespace qualification could indeed be a better long-term solution.

   However, I think there is a separate compiler regression behind this example. In 1.17, it appears that all decorators on a concrete enum are skipped when the enum is first resolved from within a template declaration, not only @friendlyName.

   The behavior also changes when introducing an alias:

   alias AggregationTypeRef = AggregationType;

   Using AggregationTypeRef inside the template causes the enum decorators to run again. This suggests that the concrete enum is resolved while InTemplateDeclaration is still set.

   PR #11019 changed checkEnum to call:

   finishType(enumType, {
     skipDecorators: ctx.hasFlags(CheckFlags.InTemplateDeclaration),
   });
   

   However, enums do not appear to be included among the concrete declarations that clear InTemplateDeclaration when followed through a type reference.

   Would skipping every decorator on such an enum be considered expected? If not, I can reframe the issue around decorator execution rather than OpenAPI schema naming.
8. timotheeguerin commented on Oct 22, 2026

   

   Timothee Guerin (timotheeguerin)

   on Oct 22, 2026

   Member

   More actions

   I see yeah no that does seem like a regression, Repro without friendlyName

   model Template<T = string> {
     aggregationType: AggregationType;
   }
   
   @doc("Aggregation documentation")
   enum AggregationType {
     SUM,
     COUNT,
   }
   
   op statistics(...Template): void;

   playground
9. Timothee Guerin (timotheeguerin)

   closed this as completedin #12358on Oct 26, 2026
10. iscai-msft

    added a commit that references this issue on Oct 26, 2026

    fix(compiler): preserve decorators on concrete types referenced from …

    ...

    9c90550