fix: required client init parameters should not trigger separate ClientOptions type#10375
Merged
JoshLove-msft merged 4 commits intomainfrom Apr 17, 2026
Merged
fix: required client init parameters should not trigger separate ClientOptions type#10375JoshLove-msft merged 4 commits intomainfrom
JoshLove-msft merged 4 commits intomainfrom
Conversation
Closed
4 tasks
…arate ClientOptions type In UseSingletonInstance, skip required parameters (those without DefaultValue) when determining if a client needs a separate client-specific options type. Required parameters are inlined as constructor parameters on the client and never become properties on the ClientOptions class, so they should not trigger the creation of a separate client-specific options type. Agent-Logs-Url: https://github.com/microsoft/typespec/sessions/6c0324cb-28eb-47ca-b77e-05f5375bcea7 Co-authored-by: JonathanCrd <17486462+JonathanCrd@users.noreply.github.com>
microsoft-github-policy-service
bot
added
the
emitter:client:csharp
Copilot
AI
changed the title
[WIP] Fix bug with unintended ClientOptions generation in C#
fix: required client init parameters should not trigger separate ClientOptions type
Apr 14, 2026
…ameters The DefaultValue check was too broad — it also skipped InputPathParameters like subscriptionId (required, no default), incorrectly allowing multi-service clients to share the singleton options type. Narrow the check to only apply to InputMethodParameter (from @@clientInitialization), preserving the original behavior for other parameter types. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
commit: |
Contributor
|
No changes needing a change description found. |
Multi-service clients need client-specific options for service-specific API version properties, so UseSingletonInstance now returns false for them explicitly. Also adds singleton reset to ClientProviderTests.SetUp to prevent state leaking between tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JoshLove-msft
requested review from
JoshLove-msft,
ShivangiReja,
christothes,
jorgerangel-msft,
joseharriaga,
jsquire and
m-nash
as code owners
jsquire
approved these changes
Apr 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
UseSingletonInstanceinClientOptionsProvidertreated all non-standard client parameters as requiring a separate client-specificClientOptionsclass. But required parameters (noDefaultValue) never become properties on the options class—they're inlined as constructor parameters on the client. This caused unnecessary per-client options types when using@@clientInitializationwith required parameters in multi-client scenarios.Changes
ClientOptionsProvider.cs: Addedparameter.DefaultValue != nullcheck inUseSingletonInstanceso only optional parameters (which actually become options properties) trigger a separate client-specific options type. This aligns the singleton decision logic withBuildProperties, which already filters onDefaultValue != null.ClientOptionsProviderTests.cs: AddedMultipleClientsWithRequiredCustomParametersShareSingletonOptionstest covering the multi-client scenario where a required custom parameter should still share the singleton options.Before/After
Before: Generates
KnowledgeBaseRetrievalClientOptions(separate, unnecessary options type)After: Shares singleton
<ServiceName>ClientOptionswith other clients in the library