You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Java response schema JavaDoc marks read-required properties on JSON Merge Patch models as optional #12449
For a model used in JSON Merge Patch (application/merge-patch+json), a required property with @visibility(Lifecycle.Read, Lifecycle.Update) represents a field initialized by the service on creation and always returned in responses, while remaining optional in PATCH requests and omitted in Create requests.
After microsoft/typespec#12378 (released in @azure-tools/typespec-java0.48.4, following up on Azure/typespec-azure#5721), ModelPropertyMapper sets both required = false and requiredForCreate = false on such properties so model setter JavaDoc no longer falsely claims "Required when create the resource."
However, ClientMethodTemplateBase.responseBodySchemaJavadoc renders Response Body Schema JavaDoc using those same request-oriented flags (property.isRequired() and property.isRequiredForCreate()):
As a result, Response Body Schema JavaDoc documents a read-required property as (Optional) (and documents create-required properties on the same response model as (Optional, Required on create) instead of (Required)).
The Java client emitter uses request-oriented requiredness flags when generating Response Body Schema JavaDoc, causing required response properties on merge-patch models to be documented as optional. The existing patch.tsp fixture provides a direct minimal reproduction.
ModelPropertyMapper intentionally adjusts required and requiredForCreate for merge-patch request/setter semantics. ClientMethodTemplateBase.responseBodySchemaJavadoc then reuses those flags for response documentation, where the original read-view requiredness should apply. This affects @typespec/http-client-java generated method JavaDoc and can also mislabel create-required properties nested in the same response model. Searches for the JavaDoc method/flags and merge-patch symptom found related merge-patch issues, but none describing this same response-documentation root cause.
📝 Suggested next steps
Derive Response Body Schema requiredness from response/read serialization semantics rather than request setter flags.
Add generated-output assertions for read-required, create-required, optional, and nested dictionary properties in the existing patch fixture.
Activity
github-actions commentedon Oct 30, 2026
🎯 Issue Triage
The Java client emitter uses request-oriented requiredness flags when generating Response Body Schema JavaDoc, causing required response properties on merge-patch models to be documented as optional. The existing
patch.tspfixture provides a direct minimal reproduction.Category: Bug
Area:
emitter:client:java🔗 [Playground Reproduction]((typespec.io/redacted)
📋 Reproduction code
🔍 Analysis
ModelPropertyMapperintentionally adjustsrequiredandrequiredForCreatefor merge-patch request/setter semantics.ClientMethodTemplateBase.responseBodySchemaJavadocthen reuses those flags for response documentation, where the original read-view requiredness should apply. This affects@typespec/http-client-javagenerated method JavaDoc and can also mislabel create-required properties nested in the same response model. Searches for the JavaDoc method/flags and merge-patch symptom found related merge-patch issues, but none describing this same response-documentation root cause.📝 Suggested next steps