Skip to content

[http-client-csharp] Lazily resolve TypeProvider FQN in AddTypeToKeep to prevent stale namespace after visitor changes#10273

Draft
Copilot wants to merge 3 commits intomainfrom
copilot/fix-stale-fqn-storage
Draft

[http-client-csharp] Lazily resolve TypeProvider FQN in AddTypeToKeep to prevent stale namespace after visitor changes#10273
Copilot wants to merge 3 commits intomainfrom
copilot/fix-stale-fqn-storage

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 6, 2026

AddTypeToKeep(TypeProvider) eagerly snapshots type.Type.FullyQualifiedName at call time (during constructor), but visitors like NamespaceVisitor run later and change the namespace. The stored FQN becomes stale, so PostProcessor.ShouldKeepType() fails to match, silently internalizing models that have @@access(public).

Changes

  • CodeModelGenerator.cs: Store TypeProvider references in HashSet<TypeProvider> instead of eagerly resolving to strings. AdditionalRootTypes / NonRootTypes are now computed properties that resolve FQNs lazily at access time (post-visitors). The AddTypeToKeep(string) overload is unchanged.
// Before: FQN captured at construction time, before visitors run
public void AddTypeToKeep(TypeProvider type, bool isRoot = true)
    => AddTypeToKeep(type.Type.FullyQualifiedName, isRoot);

// After: reference stored, FQN resolved lazily when accessed
internal HashSet<string> AdditionalRootTypes =>
    [.. _additionalRootTypeNames, .. _additionalRootTypeProviders.Select(t => t.Type.FullyQualifiedName)];
  • ModelProviderTests.cs: Added PublicModelTypeToKeepUpdatesAfterNamespaceChange — simulates a visitor namespace change and asserts AdditionalRootTypes contains the post-visitor FQN.

@microsoft-github-policy-service microsoft-github-policy-service bot added the emitter:client:csharp Issue for the C# client emitter: @typespec/http-client-csharp label Apr 6, 2026
Copilot AI changed the title [WIP] Fix stale FQN storage in AddTypeToKeep method [http-client-csharp] Lazily resolve TypeProvider FQN in AddTypeToKeep to prevent stale namespace after visitor changes Apr 6, 2026
Copilot AI requested a review from haiyuazhang April 6, 2026 18:29
@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new bot commented Apr 7, 2026

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@10273

commit: 6fe0b22

Copy link
Copy Markdown
Contributor

@jorgerangel-msft jorgerangel-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please also run a regen preview?

}

internal HashSet<string> AdditionalRootTypes { get; } = [];
private readonly HashSet<string> _additionalRootTypeNames = [];
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really need to create these additional hashsets? Is there possibly another way we can do this using just the original sets?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

emitter:client:csharp Issue for the C# client emitter: @typespec/http-client-csharp

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[http-client-csharp] AddTypeToKeep stores stale FQN after visitor namespace changes, causing public models to be internalized

3 participants