XYShape accepts a WITHIN query with a line geometry, which LatLonShape rejects, and silently returns only the points lying on the line

LatLonShape.newLineQuery(field, QueryRelation.WITHIN, line) throws IllegalArgumentException ("LatLonShapeQuery does not support WITHIN queries with line geometries"), and so do LatLonPoint and LatLonDocValuesField; XYShape threw too, up to 8.4.1 ("XYShapeLineQuery does not support WITHIN queries"). Since 8.5.0, XYShape.newLineQuery(field, WITHIN, xyLine) and XYShape.newGeometryQuery(field, WITHIN, ...) with an XYLine anywhere in the array are accepted: LUCENE-9194 deleted XYShapeLineQuery and routed line queries to the generic XYShapeQuery, whose constructor adds no check of its own on the relation and the geometries. The accepted query then answers by shape type: an indexed point lying on the line matches (a point-on-line test), an indexed line segment never does, because Line2D.containsLine always returns false. For the line (0,0)-(10,0), the segment (2,0)-(4,0) on it and the point (5,0), the WITHIN query returns only the point. No error, any index size, the default configuration; 8.5.0 to 10.6.0 and main (six releases and main executed, the other 46 releases by a jar scan, 10.6.0 by reading). The fix restores the rejection with the same validateGeometries check that LatLonShapeQuery has.

• XYShape: Lucene's field for cartesian (unitless x, y) shapes. XYShape.createIndexableFields indexes a polygon as triangles, a line as one segment per pair of consecutive vertices, and a point as a point. Its twin LatLonShape does the same for latitude/longitude.
• WITHIN: a document matches when every indexed piece of its shape lies within the query geometry. With a query line, only points and collinear segments can lie within it.
• Line2D: the query-side component built for a query line, shared by both twins.

XYShape.newLineQuery (XYShape.java:219-225 at a9779ef3c193) calls newGeometryQuery (:261-272), which returns new XYShapeQuery(field, queryRelation, xyGeometries) for every relation (only CONTAINS with several geometries is split first). The constructor (XYShapeQuery.java:41-44) is just super(field, queryRelation, geometries);; the superclass (SpatialQuery.java:74-85) and XYGeometry.create (XYGeometry.java:24-44) reject only a null field or relation and null or empty geometry arrays, nothing looks at the combination of relation and geometry type. Its twin LatLonShapeQuery wraps the geometries in validateGeometries (LatLonShapeQuery.java:43-61), which throws for WITHIN with any Line in the array (excerpt; the message spans :54-56 in the source):

if (geometries != null && queryRelation == QueryRelation.WITHIN) {
  for (LatLonGeometry geometry : geometries) {
    if (geometry instanceof Line) {
      // TODO: line queries do not support within relations
      throw new IllegalArgumentException(
          "LatLonShapeQuery does not support " + QueryRelation.WITHIN + " queries with line geometries");

LatLonPointQuery.java:52-63 and LatLonDocValuesQuery.java:63-73 have the same rule and TODO, and LatLonPoint.newGeometryQuery documents it: "Line geometries are not supported for WITHIN relationship" (LatLonPoint.java:314-316).

The WITHIN leaf test (XYShapeQuery.java:108-144) checks each indexed piece against Line2D:

For a query made only of lines, Line2D.relate (Line2D.java:92-104) never returns CELL_INSIDE_QUERY, so no index cell is accepted in bulk. The answer is essentially the point and multi-point documents whose points all lie on the query line (an indexed line whose vertices all coincide is decoded as a point and would match too): a subset of any reasonable WITHIN answer. In a mixed array such as [polygon, line] the polygon component answers as usual (ComponentTree.java), and only what lies on the line is under-matched.

Line (0,0)-(10,0), segment (2,0)-(4,0) and point (5,0) indexed; XYShape.newLineQuery("shape", WITHIN, line (0,0)-(10,0)) matches 1 of 3: [point (5,0)]. XYShape.newGeometryQuery("shape", WITHIN, polygon, line) is accepted too; with a far-away polygon it returns only the point on the line. For an L-shaped query polyline (0,0)-(0,10)-(10,10), the independent reproducer's WITHIN query returns only the three indexed points on it and misses the identical polyline and the segments (0,2)-(0,8) and (3,10)-(7,10), while INTERSECTS on the same index returns exactly the 7 expected documents. LatLonShape, LatLonPoint and LatLonDocValuesField throw for the same input.

• Who. Applications that index cartesian shapes with XYShape (floor plans, CAD drawings, game maps, projected coordinates) and build a WITHIN query with an XYLine, alone or inside a geometry array such as [polygon, line], directly or through a downstream query layer. Two downstream engines' cartesian shape queries call XYShape.newGeometryQuery with the user's relation and geometry and no WITHIN + line check of their own (source reading, not executed); one of them rejects the same input on its geographic path with the comment "Line geometries and WITHIN relation is not supported by Lucene".
• Default configuration. Public, non-experimental API, no special setting. The check is missing at query construction, so codec and index layout do not matter: the finder's test uses a plain new IndexWriterConfig(), this doc's repro Lucene's randomized test configuration.
• Silent. No exception and no assertion, the same with assertions off, and the answer looks plausible because on-line points do come back.
• Blast radius. Query-time only: that query's result. The index and other queries are unaffected. Any index size.
• Not affected. LatLonShape, LatLonPoint and LatLonDocValuesField (they reject), and XYShape WITHIN queries whose geometries contain no XYLine (they never meet Line2D).
• Rare in practice. "Which shapes lie within this line" is an unusual question; no public report was found since 8.5.0 (2020). The registry rates the likelihood "rare" and the priority low.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => junit.framework.AssertionFailedError: Expected exception IllegalArgumentException but no exception was thrown
       org.apache.lucene.tests.util.LuceneTestCaseParent.expectThrows(LuceneTestCaseParent.java:1432)
       org.apache.lucene.tests.util.LuceneTestCaseParent.expectThrows(LuceneTestCaseParent.java:1418)
       org.apache.lucene.document.TestXYShapeWithinLineRejected.testWithinLineQueryIsRejected(TestXYShapeWithinLineRejected.java:28)

• The twin rejects it, with a TODO saying so. LatLonShapeQuery, LatLonPointQuery and LatLonDocValuesQuery all throw for WITHIN with a line, each with // TODO: line queries do not support within relations; LatLonPoint.newGeometryQuery documents "Line geometries are not supported for WITHIN relationship".
• XY itself rejected it until 8.5.0. XYShapeLineQuery (LUCENE-8632, 2019) documented "QueryRelation.WITHIN queries are not yet supported" and threw "XYShapeLineQuery does not support WITHIN queries"; 8.2.0 and 8.4.1 throw when run.
• The change that dropped it announced no behaviour change. LUCENE-9194's CHANGES entry: "Simplify XYShapeXQuery API by adding a new abstract class called XYGeometry. Queries are executed with input objects that extend such interface." Its PR has one approval and no word on WITHIN or lines. Eight days earlier LUCENE-9141, by the same author, folded the LatLon queries into LatLonShapeQuery and kept the check; LUCENE-9641 (2021, the same author) added the rejection to the new LatLonPointQuery and LatLonDocValuesQuery and rewrote XYShapeQuery in the same commit without adding it there. That the XY check was lost by accident is an inference from this record.
• Inconsistent with itself. A point on the line counts as within it, the identical line does not.
• Why tests never caught it. The shared random line-query test draws only from POINT_LINE_RELATIONS = {INTERSECTS, DISJOINT, CONTAINS}, so WITHIN with a line is never run; no upstream test asserts the LatLon rejection either.

The strongest case for "works as designed": WITHIN with a query line is knowingly unsupported. Line2D.containsLine is a deliberate false ("can be improved?"), the random tests exclude WITHIN for line queries, the newLineQuery javadoc speaks of shapes that "intersect" a linestring, and XYShapeQuery is @lucene.internal. Line containment is conservative elsewhere too: CONTAINS with a line query never matches an indexed line on either twin, not even the identical one (executed: XY CONTAINS (0,0)-(10,0) returns only an enclosing square; LatLon CONTAINS on the identical indexed line counts 0, INTERSECTS 1).

Why it fails: all of that explains why the operation is unsupported, which argues for rejecting it, as LatLon does and XY did, not for accepting it silently. The "intersect" wording decides nothing: LatLonShape.newLineQuery has the same sentence and rejects WITHIN, and XYShape.newPolygonQuery has it and supports WITHIN; the XYShape class javadoc says newLineQuery matches shapes "that have some QueryRelation with a linestring". @lucene.internal covers the query class, not the public factories that build it. No record shows that accepting the query was deliberate, and no author has said either way: an accident is the likely reading of the history, not a proven one. Verdict: not intended, framed as the missing rejection. The executing checks (the independent reproducer, the devil's advocate, the adjudication) rated it real. The cross-model intended-lens reviewer rated the intended argument moderate and concluded that it "justifies rejection rather than the current accepted-but-incomplete behavior". The cross-model refute-lens reviewer recorded a formal "not real" with low confidence because it could not run any code (its notes call that procedural), and agrees on the root cause.

One fix was applied in a scratch worktree at a9779ef3c193 and run through gradle (seed DEADBEEF); the alternatives were not run.

In the XYShapeQuery constructor, pass the geometries through a validateGeometries method that throws IllegalArgumentException for WITHIN with any XYLine in the array, as LatLonShapeQuery does (+18/-1 lines including the XYLine import; the code below is the changed part of an unpublished file). Worth adding "Line geometries are not supported for WITHIN" to the XYShape.newLineQuery and newGeometryQuery javadoc, as LatLonPoint.newGeometryQuery has; that is not part of the validated diff.

  /** Creates a query that matches all indexed shapes to the provided polygons */
  XYShapeQuery(String field, QueryRelation queryRelation, XYGeometry... geometries) {
    super(field, queryRelation, validateGeometries(queryRelation, geometries));
  }

  private static XYGeometry[] validateGeometries(
      QueryRelation queryRelation, XYGeometry... geometries) {
    if (geometries != null && queryRelation == QueryRelation.WITHIN) {
      for (XYGeometry geometry : geometries) {
        if (geometry instanceof XYLine) {
          // line queries do not support within relations (same as LatLonShapeQuery)
          throw new IllegalArgumentException(
              "XYShapeQuery does not support "
                  + QueryRelation.WITHIN
                  + " queries with line geometries");
        }
      }
    }
    return geometries;
  }

Trade-offs

• Behaviour change. Queries accepted today start throwing: XYShape.newLineQuery(f, WITHIN, ...) and newGeometryQuery(f, WITHIN, ...) with any XYLine in the array, including mixed arrays such as [polygon, line] whose polygon part answers correctly today. That is exactly LatLon's behaviour; it needs a CHANGES entry, and whether it also needs a MIGRATE note or goes to main only is the maintainers' call. Downstream engines that pass the relation through would get an IllegalArgumentException for cartesian WITHIN with a linestring, as for geo shapes.
• Cost: one loop over the query geometries at construction; nothing at search time.
• Scope: the check sits in XYShapeQuery only. XYShapeDocValuesQuery extends BaseShapeDocValuesQuery directly and would not get it, but no public API builds it with a line today: XYShape.newSlowDocValuesBoxQuery passes only an XYRectangle (XYShape.java:214-217) and ShapeDocValuesField.newGeometryQuery always throws (ShapeDocValuesField.java:89-95).

What the checks validated

• Stock main a9779ef3c193 (scratch worktree, gradle, seed DEADBEEF): the repro fails 2 of 3 with assertions on and off; the closest suites, every XY shape class of lucene/core/document (TestXY*Shape*: 11 classes, BKD and doc-values), pass: 69 tests, 9 skipped, 0 failures.
• With the fix: the repro passes 3 of 3 with assertions on and off; the same 11 classes pass (72 tests with the repro, 9 skipped, 0 failures); every geo and shape suite of lucene/core (the geo package, document *Shape*, TestXY* and TestLatLon*, search TestXY* and TestLatLon*; 54 classes with the repro) passes: 587 tests, 40 skipped, 0 failures.
• Lint and format: ecjLintMain passes with the fix. The first run flagged the test file only (a javadoc line wrap and an unused catch parameter, now an assertion that the message names WITHIN); with the edited test ecjLintTest and checkGoogleJavaFormat pass, and the edited test passes 3 of 3 with the fix and fails 2 of 3 on stock, assertions on and off. The suite runs above used the test before that edit.
• Classpath runner on the stock main jars: 3 run, 2 failed with assertions on and off; with the fix shadowed, 3 run, 0 failed.
• fix.diff and fix-with-test.diff (the fix plus the test as a new file) pass git apply --check on a9779ef3c193 (the recorded tree still listed the test file as an intent-to-add entry; the independent fact check re-ran both on a clean tree: both apply).
• Earlier hunt runs: the finder's shadow fix passes its own test and 8 upstream XY shape test classes (40 tests started: 33 passed, 7 aborted by test assumptions, 0 failed); the follow-up re-run passes the version-neutral and the finder's tests with the fix (3 run, 0 failed, assertions off).

Make Line2D.containsLine return true when the indexed segment lies on the query polyline, so that XY WITHIN with a line becomes a supported query.

Trade-offs

Larger and riskier: a segment can span several collinear pieces of the query polyline or of a multi-line query; Line2D is shared with LatLon, whose quantized coordinates may no longer lie exactly on the original line, so LatLon would likely keep rejecting and the twins would diverge on purpose; CONTAINS semantics for lines (conservative today) would deserve the same look; and it needs new random-test coverage.

State in the XYShape javadoc that WITHIN with lines is unsupported.

Trade-offs

Compatibility-preserving, and a valid choice if the maintainers prefer to declare the combination unsupported without a behaviour change. It keeps the silent partial answer for every caller who does not read the javadoc, though, and does not restore the 8.4.1 rejection or parity with LatLon.

Method: non-formal static comparison of sibling implementations, in a hunt unit on twin families (2026-10-26, main ea57360912ed).

• A token-level diff of 96 sibling class pairs (Float/Double, Int/Long, vector Float/Byte, LatLon/XY and others), normalised per family, listed members present in only one twin. In the geo family, LatLonShapeQuery.validateGeometries exists only on the LatLon side; a class-file scan for the same idiom agreed (present in LatLonShapeQuery, absent in XYShapeQuery).
• The git history showed that XYShapeLineQuery rejected WITHIN until LUCENE-9194 deleted it, eight days after LUCENE-9141 kept the same check for LatLon.
• A targeted public-API JUnit then showed the query accepted and returning only the on-line point. It was checked by an independent reproducer with its own test, an intended-behaviour devil's advocate with executed controls, reading-only reviews by a model from another family (OpenAI GPT-5.6), an adjudication, a history, prior-report and security follow-up with a 19-run version sweep, an audit, and this doc's gradle runs on a9779ef3c193.