Skip to content
This repository was archived by the owner on May 14, 2026. It is now read-only.
This repository was archived by the owner on May 14, 2026. It is now read-only.

Exclude fields from query params if the fields are already configured for path params or body. #1041

Description

@blakeli0

We should exclude fields from query params if the fields are already configured for path params or body.
See here for the detailed rules for mapping http annotation to body/path param/query param.

// ## Rules for HTTP mapping
//
// 1. Leaf request fields (recursive expansion nested messages in the request
//    message) are classified into three categories:
//    - Fields referred by the path template. They are passed via the URL path.
//    - Fields referred by the [HttpRule.body][google.api.HttpRule.body]. They are passed via the HTTP
//      request body.
//    - All other fields are passed via the URL query parameters, and the
//      parameter name is the field path in the request message. A repeated
//      field can be represented as multiple query parameters under the same
//      name.
//  2. If [HttpRule.body][google.api.HttpRule.body] is "*", there is no URL query parameter, all fields
//     are passed via URL path and HTTP request body.
//  3. If [HttpRule.body][google.api.HttpRule.body] is omitted, there is no HTTP request body, all
//     fields are passed via URL path and URL query parameters.

The current logic does not exclude fields that are more than one level deep. We need to either traverse all the leaf level fields and exclude field in the generator or pass the excluded fields to gax-java.

Activity

  1. added
    type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
    priority: p2Moderately-important priority. Fix may not be included in next release.
    on Sep 22, 2022
  2. added
    priority: p3Desirable enhancement or fix. May not be included in next release.
    and removed
    priority: p2Moderately-important priority. Fix may not be included in next release.
    on Dec 21, 2022
  3. blakeli0 commented on Sep 24, 2024

    @blakeli0
    ContributorAuthor

    This is a very niche use case and we haven't seen any customer issues for it in the last two years. In addition, we should probably add this validation in upstream tools to prevent a field being configured multiple times. Closing this as not planned.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: p3Desirable enhancement or fix. May not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions