Geo3dRectangleShape.reset() keeps the old minX/maxX/minY/maxY, so BBoxStrategy shape values and overlap-ratio scores are wrong in the Geo3d spatial context

In the opt-in Geo3d spatial context (Geo3dSpatialContextFactory, @lucene.experimental), Geo3dRectangleShape.reset(minX, maxX, minY, maxY) rebuilds the wrapped spatial3d GeoBBox but never assigns the four fields that getMinX()..getMaxY(), getWidth(), getHeight() and getCrossesDateLine() return. The reset rectangle equals the new box but reports the old coordinates. BBoxStrategy's shape-value source reuses one rect(0, 0, 0, 0) per getValues call and resets it for every document, so makeShapeValueSource() reports (0, 0, 0, 0) for every document and makeOverlapRatioValueSource() scores against that point: a box equal to the query scores 0.0 instead of 1.0. No exception. Lucene's own matching and indexing never reset a rectangle, so with freshly built rectangles they are unaffected, and distances use the rebuilt inner box; only a rectangle that application code resets itself and then queries with or indexes carries the stale bounds there. It came in with LUCENE-7951 in 7.1.0 (2017) and is in every release since and on main; a 4-line fix (assign the four fields in reset) passes every repro and the module's tests, and should land together with, or after, the fix for the class's separate getCrossesDateLine bug.

• Spatial context: spatial4j's SpatialContext builds and relates shapes. Geo3dSpatialContextFactory (opt-in, @lucene.experimental) makes one whose shapes wrap spatial3d (Geo3d) shapes; its rectangles are Geo3dRectangleShape.
• Rectangle.reset: spatial4j's "Expert: Resets the state of this shape given the arguments. This is a performance feature to avoid excessive Shape object allocation". A caller keeps one rectangle and overwrites it instead of allocating a new one.
• BBoxStrategy (@lucene.experimental): indexes a box as four numbers (and a dateline flag). makeShapeValueSource() reads each document's box back from doc values; makeOverlapRatioValueSource(queryBox, proportion) scores each document by how much its box and the query box overlap (1.0 when they are equal).

1. Geo3dRectangleShape keeps minX, maxX, minY, maxY as fields (Geo3dRectangleShape.java:39-42); Geo3dShapeFactory.rect passes the caller's raw bounds into them (Geo3dShapeFactory.java:163-173). getMinX()..getMaxY() return them (:132-150), and getWidth(), getHeight() and getCrossesDateLine() are computed from them (:118-130, :152-155).
2. reset (:100-111) builds a new GeoBBox into the wrapped shape, clears the center and boundingBox caches, and returns. It never writes the four fields.
3. So the object contradicts itself: equals and the rectangle's own relate use the new GeoBBox (Geo3dShape.java:55-79, :160-164), and so does getCenter(), but the getters return the old box, and so does any code that reads them (spatial4j's RectangleImpl.relate(Rectangle) reads the other rectangle's getters).
4. BBoxValueSource creates one rect(0, 0, 0, 0) in each getValues(LeafReaderContext) call (BBoxValueSource.java:55-56, "// reused"; each call reads one segment, and a segment can get several calls) and resets it to each document's four doc values (:74). In the Geo3d context every document read through it therefore reports (0, 0, 0, 0).
5. BBoxOverlapRatioValueSource.score computes the overlap height from the target's getMinY()/getMaxY() (BBoxOverlapRatioValueSource.java:148-156): for the query (10, 20, 30, 40) and the target (0, 0, 0, 0) it is min(40, 0) - max(30, 0) = -30, so the score is 0 with "No intersection".

The default spatial4j context (SpatialContext.GEO) gives the "expected" column on main.

• Matching: BBoxStrategy.makeQuery reads the query rectangle's getters but never calls reset, so a freshly built query box matches correctly (code reading). In a 300-document probe with the class's separate getCrossesDateLine fix applied, the 125 queries return exactly the arithmetic truth with and without this fix. Without that fix, stock main already mismatches 62 of the 125 queries because of it, with identical aggregate counts with and without this fix (hit sets not compared query by query).
• Distances: makeDistanceValueSource measures to getCenter(), which comes from the new GeoBBox (the table's last row). The Geo3d context measures with Geo3dDistanceCalculator, the default context with spatial4j's haversine calculator; both give degrees on the default sphere.
• The index: documents are indexed from freshly built rectangles, so the stored numbers are right and need no reindex after a fix. Only a rectangle that the application has reset itself would be indexed with stale bounds and a stale dateline flag, and those documents would need a reindex; used as a query box, such a rectangle would also match by its stale bounds (code reading).
• RecursivePrefixTreeStrategy, the default spatial4j contexts and Lucene's core geo types do not use this method.

• Who is hit. Applications that pair the Geo3d spatial context (Geo3dSpatialContextFactory, @lucene.experimental) with BBoxStrategy (@lucene.experimental) and read makeShapeValueSource() or rank by makeOverlapRatioValueSource(); and any application code that calls reset on a Geo3d rectangle. Downstream, by reading Solr's code only (not run): Solr maps spatialContextFactory="Geo3D" to this context, and its BBoxField builds the overlapRatio score on these shape values; one public downstream configuration uses such a field.
• Default vs opt-in. Opt-in: two experimental pieces together, plus the value-source path. Within that pairing it is deterministic, assertions on or off: every document reads back as (0, 0, 0, 0), so every stored box other than (0, 0, 0, 0) itself is wrong (269 of 269 generated boxes in the probe).
• What goes wrong. Every shape value is (0, 0, 0, 0). Overlap relevance is computed against the point (0, 0): 0.0 for every document when the query box does not contain that point (all ties, so ranking by overlap does nothing), and wrong in other ways when it does (the box -10..10 x -10..10 scores itself 0.5). Scores are wrong in general; a few can be right by coincidence.
• At scale (follow-up probe: 300 boxes in 3 segments, 31 deleted, two tenants, 25 query boxes scored by overlap ratio): all 269 live documents report (0, 0, 0, 0). With the class's separate getCrossesDateLine bug fixed to isolate this one, 141 of 141 returned scores and the top-10 order of 16 of 25 queries differ from the default spatial4j context; with both fixes 0 of 141 and 0 of 25.
• Silent, but contained. No exception or hang; explain says "No intersection". This bug does not change matching with freshly built query boxes, filter clauses or deletions (0 other-tenant and 0 deleted documents in the probe, all scores in [0, 1]), and an index built from fresh rectangles holds the right numbers. On stock main the same probe's matching was already wrong for 62 of 125 queries, and 77 of 218 scored documents did not satisfy the query, because of the class's separate getCrossesDateLine bug; with that fix both are 0.
• How likely. Rare: the pairing appears little used (no upstream test combines the Geo3d context with BBoxStrategy), and nobody reported it in the nine years since 7.1.0.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: expected:<10.0> but was:<-50.0>
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.failNotEquals(Assert.java:835)
       org.junit.Assert.assertEquals(Assert.java:555)
       org.junit.Assert.assertEquals(Assert.java:685)
       org.apache.lucene.spatial.spatial4j.TestGeo3dRectangleResetBounds.testResetReplacesMinX(TestGeo3dRectangleResetBounds.java:30)

• The contract. spatial4j 0.8 Rectangle.reset: "Expert: Resets the state of this shape given the arguments. This is a performance feature to avoid excessive Shape object allocation as well as some argument error checking. Mutable shapes is error-prone so use with care." getMinX(): "The left edge of the X coordinate." spatial4j's RectangleImpl.reset assigns minX, maxX, minY and maxY (four putfields in its bytecode). BBoxValueSource uses reset for exactly the documented purpose, and ShapeValues.value() "Returns a Shape for the current document".
• The class contradicts itself. After reset, equals and the rectangle's own relate see the new box and the getters the old one.
• The fields are the coordinates, not a constructor cache. In LUCENE-7951 (#9000) the author explained that the 6-argument constructor exists because wide Geo3d rectangles (more than 180 degrees of longitude) cannot compute their longitude bounds from the GeoBBox, and the reviewer accepted it.
• History. In the PR's first version of the class (lucene-solr#246, ea31e5ce0f, 2017-09-07) the bounds were computed lazily from a cached LatLonBounds, and reset cleared the cache (bounds = null;). PR commit cfbac2fb00 (2017-09-12) replaced the cache with the four stored fields and removed bounds = null; from reset without assigning them. No review comment on #246 and none of the 43 comments on #9000 mention reset.
• The sibling resets are complete. Geo3dPointShape.reset and Geo3dCircleShape.reset rebuild the wrapped shape, and their getters read it; only the rectangle caches coordinates, and only it forgets them.
• Tests. No test under lucene/spatial-extras/src/test calls reset(, and TestBBoxStrategy uses only spatial4j's own contexts. No test, CHANGES or MIGRATE entry accepts the current behaviour.

The strongest case for "intended" (an intended-behaviour checker): the public Lucene classes involved (Geo3dSpatialContextFactory, Geo3dRectangleShape, BBoxStrategy) are @lucene.experimental, BBoxValueSource is @lucene.internal and reuses the rectangle on purpose, spatial4j calls mutable shapes "expert" and "error-prone", the Geo3d context with BBoxStrategy is untested and partly unsupported (Geo3dShape.getArea throws UnsupportedOperationException), and nobody has reported it since 2017.

Why it fails: the "expert" warning is about callers sharing a mutable object, not a licence for reset to update half of it; experimental status warns about API changes, not wrong values; the wrong values are read right away, for the current document, with ordinary boxes; nothing documents the pairing as unsupported, and where something really is unsupported (getArea) it throws instead of returning wrong numbers; and the direct trigger, reset on a rectangle from the Geo3d factory, needs no BBoxStrategy at all. Verdict: not intended, a defect (the adjudication and independent checks; the cross-model reviewer rated the intended-behaviour argument weak under both of its lenses).

One option was built and validated in a scratch worktree at a9779ef3c193 with gradle (JDK 25), alone and together with the getCrossesDateLine fix, and with the standalone runner against every repro (patched class shadowed). The other three were weighed and not built. Any fix needs a regression test (this doc's test is one).

Add four assignments after the new GeoBBox is built in Geo3dRectangleShape.reset (after line 108). A reset rectangle then matches the one Geo3dShapeFactory.rect builds from the same arguments (the factory passes the raw arguments to the 6-argument constructor). Because the assignments come after makeGeoBBox, an invalid argument that makes it throw leaves the object unchanged. It restores what bounds = null; did before the bounds became fields.

@@ -106,6 +106,10 @@ public class Geo3dRectangleShape extends Geo3dShape<GeoBBox> implements Rectangl
             minY * DistanceUtils.DEGREES_TO_RADIANS,
             minX * DistanceUtils.DEGREES_TO_RADIANS,
             maxX * DistanceUtils.DEGREES_TO_RADIANS);
+    this.minX = minX;
+    this.maxX = maxX;
+    this.minY = minY;
+    this.maxY = maxY;
     center = null;
     boundingBox = null;
   }

Trade-offs

• Smallest change, at the defect; the same hunk as the finder's fix. It also makes getWidth() and getHeight() right after a reset, since they read the fields, and gives getCrossesDateLine() the new bounds as input; that getter's formula stays wrong for boxes that span longitude 0 until the class's separate getCrossesDateLine fix lands (with this fix alone: crossesDateLine=true and 19.0 for -10..10 x -10..10; with both: false and 1.0).
• Fix ordering. On main the stale (0, 0, 0, 0) happens to hide the class's separate getCrossesDateLine bug (it returns maxX > 0 && minX < 0) from the overlap scorer. With only this fix, boxes that span longitude 0 reach the scorer with the wrong flag: the self-overlap of -10..10 x -10..10 is 19.0 with assertions off and an AssertionError: 19.0 from the queryRatio assertion with assertions on; in the 300-document probe 28 of 218 scores fell outside [0, 1] with assertions off and 14 of 25 queries threw with assertions on. With both fixes: 1.0, and 0 and 0. So land it together with that fix (one PR with both lines and both tests is simplest) or after it.
• No reindex for indexes built from fresh rectangles. Lucene's indexing does not call reset, so existing BBoxStrategy indexes built from factory rectangles hold the right numbers and read back correctly after the fix. An application that indexed rectangles it had reset itself stored stale bounds and needs to reindex those documents (code reading).

What the checks validated

• Gradle, scratch worktree at a9779ef3c193, seed DEADBEEF, this doc's test added: it fails 3 of 3 on stock main (assertions on and off) and passes with the fix.
• ./gradlew :lucene:spatial-extras:check with the fix passes: 27 suites, 120 tests (the module's 117 plus the 3 new), 5 skipped, 0 failures, and the format, ecjLint and forbiddenApis checks. The suites include TestBBoxStrategy, TestGeo3d, TestGeo3dRpt, both Geo3d RectRelation tests, TestDistanceStrategy and TestPointVectorStrategy.
• TestBBoxStrategy, TestDistanceStrategy and TestGeo3d* 10 times with a random root seed and assertions off: 480 tests, 50 skipped, 0 failures.
• With the getCrossesDateLine fix added: ./gradlew :lucene:spatial-extras:check passes (120 tests, 5 skipped, 0 failures); the fix-order probe gives 1.0 for both boxes, assertions on and off.
• Standalone, fix shadowed: this doc's test 3/3 (assertions on and off, alone and with both fixes); earlier, by the hunt: the finder's 3/3, the independent reproducer's 7/7, the cross-model reviewer's and the devil's advocate's own tests, the history test on 7.1.0 and main, the bridge model clean (0 of 10,000 resets, with the hunt's first five fixes applied together, not this fix alone), and the 300-document probe with both fixes (0 of 141 scores differ from the default context).

Call the existing setBoundsFromshape() at the end of reset.

Trade-offs

A reset rectangle would then differ from a freshly built one: bounds derived from a GeoBBox do not round-trip exactly (-50 comes back as -49.999999999999986) and cannot be computed for boxes wider than 180 degrees of longitude, which is why the 6-argument constructor exists. Not recommended.

Build a fresh ctx.getShapeFactory().rect(...) per document instead of rect.reset(...).

Trade-offs

Fixes only the in-tree path: Rectangle.reset stays broken for application code, and the class keeps contradicting itself. By code reading it costs one extra object per document (reset already builds a new GeoBBox per document). Not sufficient on its own.

Compute the bounds lazily from a cached LatLonBounds and clear the cache in reset.

Trade-offs

Reintroduces the wide-rectangle problem that the stored fields solved. Not recommended.

Method: model-based differential testing (non-formal; the finder tagged it semi-formal), in a hunt unit on the spatial4j bridge to spatial3d.

• While modelling the shapes' mutators, the finder wrote the rule G6 of the bridge model: a shape changed with reset must equal, and report the same values as, a freshly built shape with the same arguments.
• The harness Geo3dBridgeDiff checked G6a on 10,000 random rectangle resets (5,000 on the SPHERE and 5,000 on the WGS84 planet model): every reset rectangle kept its old getMinX()..getMaxY() while equals said it matched the fresh one; with the hunt unit's first five fixes applied together (this one among them), 0 of 10,000.
• The finder then looked for in-tree callers of Rectangle.reset, found BBoxValueSource, and wrote a public-API JUnit on the stock main jar: a direct reset, BBoxStrategy shape values, and the overlap-ratio score compared with the default spatial4j context. It fails 3 of 3.
• The same rule's circle family (G6d) also flagged Geo3dCircleShape.reset on WGS84 (a reset circle never equals a fresh one); it has no in-tree caller and is recorded as a lead only.