Skip to content

[BUG] shape should not be required in GeoShapeQueryField (blocks pre-indexed shape queries in generated clients) #1160

Description

@lsh1215

What is the bug?

The GeoShapeQueryField schema marks shape as required, but the OpenSearch geo_shape query supports a pre-indexed shape form that uses indexed_shape and no sibling shape. Because this spec is the source of truth for generated clients, the requiredness propagates downstream and makes it impossible to build a pre-indexed shape query with the generated classes.

Current schema (spec/schemas/_common.query_dsl.yaml, main):

GeoShapeQueryField:
  type: object
  properties:
    indexed_shape:
      $ref: '#/components/schemas/FieldLookup'
    shape:
      $ref: '#/components/schemas/GeoShape'
    relation:
      $ref: '_common.yaml#/components/schemas/GeoShapeRelation'
  required:
    - shape

Per the docs, shape and indexed_shape are alternatives (one or the other, not both):
https://docs.opensearch.org/latest/query-dsl/geo-and-xy/geoshape/#using-a-pre-indexed-shape-definition

How can one reproduce the bug?

A pre-indexed shape query is valid against OpenSearch. This is the pre-indexed example from the docs (index pre-indexed-shapes, document id search_triangle, path boundaries):

GET /testindex/_search
{
  "query": {
    "geo_shape": {
      "location": {
        "indexed_shape": {
          "index": "pre-indexed-shapes",
          "id": "search_triangle",
          "path": "boundaries"
        },
        "relation": "WITHIN"
      }
    }
  }
}

Validating this body against the current schema fails because shape is missing, even though the query has no inline shape by design.

How did this happen? (timeline)

  • PR Update spec and add tests for xy, geo shape, and geo bounding box query #531 introduced the geo shape field schema (then named GeoShapeField) with required: - shape. At that time the schema had only shape and relation, with no indexed_shape, so requiring shape was consistent.
  • indexed_shape was added to the schema later, but required: - shape was not revisited. That produced the current mismatch: indexed_shape is optional while shape stays mandatory.

(Origin PR: #531)

Downstream impact

Reported in the Java client: opensearch-project/opensearch-java#2011

Maintainer confirmation on that issue (xluo-aws):

  • either shape or indexed_shape can be used, but not both;
  • the fix should be made in the API spec first, otherwise the change in the client repo is overwritten by regeneration.

Generated client repro (opensearch-java):

new Query.Builder()
    .geoShape(new GeoShapeQuery.Builder()
        .field("some")
        .shape(shape -> shape.indexedShape(i -> i.index("some").id("id").path("path")))
        .build())
    .build();
// GeoShapeQueryField requires `shape`, so an indexed_shape-only query can't be built.

What is the expected behavior?

The schema should allow a GeoShapeQueryField that provides indexed_shape without shape, matching the documented pre-indexed shape query.

Open questions for maintainers (how to model the contract)

I'd like to align on the intended schema shape before opening a PR:

  1. Is the contract "exactly one of shape / indexed_shape" (mutually exclusive), or "at least one of them"? The docs read as one-or-the-other.
  2. How should this be expressed in the spec: simply dropping required: - shape, or using oneOf / minProperties / another construct that the codegen and existing spec conventions support?
  3. XyShapeQueryField has the same issue. It carries an identical required: - shape alongside an optional indexed_shape, so it likely needs the same treatment (it was introduced as XyShapeField in Update spec and add tests for xy, geo shape, and geo bounding box query #531 and later renamed, same as the geo variant).
  4. Which spec tests should be updated or added? There are existing tests under tests/default/_core/search/query/geo_shape_*.yaml from Update spec and add tests for xy, geo shape, and geo bounding box query #531, but none cover the indexed_shape path.

Additional context

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions