Skip to content

[Bug]: Java response schema JavaDoc marks read-required properties on JSON Merge Patch models as optional #12449

Open

Description

@Y-Sindo

Describe the bug

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-java 0.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)).

Expected in Response Body Schema:

state: String (Required)

Actual in Response Body Schema:

state: String (Optional)

Reproduction

This is already reproduced in the test fixture added by microsoft/typespec#12378:

  1. In patch.tsp#L26-L27, Resource.state is defined as required (no ?) with @visibility(Lifecycle.Read, Lifecycle.Update):
    model Resource {
      @visibility(Lifecycle.Read)
      id: string;
    
      @visibility(Lifecycle.Create)
      name: string;
    
      description?: string;
    
      @visibility(Lifecycle.Read, Lifecycle.Update)
      state: string;
    
      map: Record<InnerModel>;
    }
  2. In the generated PatchClient.java#L77-L90, the Response Body Schema JavaDoc marks state as (Optional) and map as (Optional, Required on create):
     * <p><strong>Response Body Schema</strong></p>
     * 
     * <pre>
     * {@code
     * {
     *     id: String (Required)
     *     name: String (Required)
     *     description: String (Optional)
     *     state: String (Optional)
     *     map (Optional, Required on create): {
     *         String (Required): {
     *             name: String (Optional, Required on create)
     *             description: String (Optional)
     *         }
     *     }
     * }
     * }
     * </pre>
    

Checklist

Activity

  1. added
    bugSomething isn't working
    emitter:client:javaIssue for the Java client emitter: @typespec/http-client-java
    on Oct 30, 2026
  2. github-actions commented on Oct 30, 2026

    @github-actions
    Contributor

    🎯 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.tsp fixture provides a direct minimal reproduction.

    Category: Bug

    Area: emitter:client:java

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

    📋 Reproduction code
    model Resource {
      @visibility(Lifecycle.Read)
      id: string;
    
      @visibility(Lifecycle.Create)
      name: string;
    
      description?: string;
    
      @visibility(Lifecycle.Read, Lifecycle.Update)
      state: string;
    
      map: Record;
    }
    🔍 Analysis

    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.

    Generated by Agentic Triage

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

Metadata

Metadata

Labels

bugSomething isn't workingemitter:client:javaIssue for the Java client emitter: @typespec/http-client-java

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions