Tessellator.cureLocalIntersections adds each triangle it cuts off twice, so LatLonShape and XYShape index that triangle twice and the shape doc-values centroid counts its area twice

LatLonShape and XYShape index a polygon as the triangles that Tessellator.tessellate returns: one indexed Triangle field and one doc-values triangle per list entry. When ear clipping gets stuck on a ring that crosses itself a little, the Tessellator's cure step, cureLocalIntersections, cuts off the small triangle at the crossing and continues. It appends that triangle with two identical tessellation.add(...) calls (Tessellator.java:890 and :892, only a comment between them), so the shape is indexed with one triangle twice. The ring POLYGON((6 3, 0 6, 4 0, 3 4, 5 1, 3 2, 6 3)), accepted by the default checkSelfIntersections = false, is tessellated into 3 distinct triangles but indexed as 4, because (3,2) (4,0) (3,4) is stored twice; XYShapeDocValuesField.numberOfTerms() is 4 and getCentroid() is (3.0, 3.254), the area-weighted centroid of the 4 entries with the cut-off triangle counted twice, instead of (2.965, 3.386), that of the 3 distinct triangles. No query result changed in the executed box-query sweeps (129,472 queries, the same counts with and without the duplicate). The second call was left by a 2019 edit (LUCENE-8620, first released in 8.3.0); 8.2.0 added the triangle once, as earcut, which the class ports, does. On valid polygons, non-zero-area duplicates were found only together with LFV-210 (a hole touching the outer ring), whose fix removes them; with it fixed, 3 of about 12 million valid lattice polygons still store a zero-area cure triangle twice, through LFV-793. Deleting line 890 fixes it: the repro passes, and the geo and shape test suites pass with assertions on and off.

• Tessellation: Tessellator.tessellate cuts a polygon into triangles by ear clipping: it repeatedly cuts off a corner triangle (an ear) that lies inside the ring. Each triangle becomes one indexed Triangle field (createIndexableFields) and one doc-values triangle (createDocValueField).
• Cure step: when no ear is found, the Tessellator first filters points and retries, then calls cureLocalIntersections (Tessellator.java:671-679), which looks for a node whose previous edge intersects the edge after the next node (a crossing, or some touching configurations), cuts off that small triangle, removes the two nodes in between and lets ear clipping continue. It is meant for rings with small self-crossings.

1. In cureLocalIntersections (Tessellator.java:854-903), for a = node.previous, nextNode = node.next, b = nextNode.next, edge (a, node) crosses edge (nextNode, b) (:862-878). For the example a = (4,0), node = (3,4), nextNode = (5,1), b = (3,2): edge (4,0)-(3,4) crosses (5,1)-(3,2) at (3.571, 1.714), one of the ring's 3 crossings.
2. It computes the three edge flags (:880-889) and then adds the triangle (a, node, b) twice:

   tessellation.add(new Triangle(a, abFromPolygon, node, bcFromPolygon, b, caFromPolygon));   // :890
   // Return the triangulated vertices to the tessellation                                      // :891
   tessellation.add(new Triangle(a, abFromPolygon, node, bcFromPolygon, b, caFromPolygon));   // :892

Nothing changes between the calls; a traced copy of the class shows the list growing to 1 at line 890 and to 2 at line 892.

1. It removes (3,4) and (5,1) (:895-896), and ear clipping finishes the ring (3,2) (6,3) (0,6) (4,0) with 2 more triangles.
2. createIndexableFields and createDocValueField turn every list entry into one stored triangle (XYShape.java:93-130, LatLonShape.java:95-132), so the cut-off triangle is stored twice. ShapeDocValues weights each triangle's centroid by its area (ShapeDocValues.java:428-453, :262-290) and writes the centroid into the doc value at index time (:491-493).

The 3 triangles are (0,6) (3,2) (6,3) with area 7.5, (0,6) (4,0) (3,2) with area 1 and (3,2) (4,0) (3,4) with area 1. LatLonShape gives the same 4 fields for 3 triangles. The stock centroid (3, 205/63) is exactly the area-weighted centroid of the 4 entries; (169/57, 193/57) is that of the 3 distinct triangles. Because the ring crosses itself, (3,2) (4,0) (3,4) and (0,6) (3,2) (6,3) overlap by 6/13, so 9.5 is a sum of triangle areas, not the area of one region. With checkSelfIntersections = true the ring is rejected ("Polygon self-intersection at lat=1.7142857142857142 lon=3.5714285714285716").

• Who. Applications that index polygons through LatLonShape or XYShape createIndexableFields or createDocValueField (the overloads without the flag pass checkSelfIntersections = false; default IndexWriterConfig and codec; one document is enough) and receive self-intersecting rings (a small self-crossing, or a ring that touches or overlaps itself). That is the input the cure step exists for: in #11767 a maintainer wrote "Small self intersections are a reality" and called the step a "best effort" clean-up.
• Effect. Per cured triangle: one extra indexed triangle (PointValues.size one higher), ShapeDocValuesField.numberOfTerms() one higher, and that triangle's area counted twice in getCentroid(). No exception, and no search result changed in the executed sweeps: 129,472 box queries on this ring, and the finder's 57,800 point-index plus 43,350 doc-values box queries over two other witnesses, give identical counts with and without the duplicate. Only XY box queries were run; the duplicate is an exact copy of a triangle that is already indexed, so every per-triangle relation it produces is one its twin already produces, and no other query is expected to change.
• Default vs opt-in. Indexing is the default path. The doc-values effects need createDocValueField; ShapeDocValuesField is @lucene.experimental, exists since 9.4.0, and nothing else in Lucene reads its getCentroid().
• Valid input. Non-zero-area duplicates on valid input were found only together with LFV-210 (a hole touching the outer ring makes the hole bridge pick the wrong vertex): POLYGON((4 2, 3 0, 1 2, 0 0, 0 4, 4 2), (2 1, 3 2, 2 2, 2 1)) indexes 8 triangles, 7 distinct, with (0,0) (3,0) (2,1), which lies outside the polygon, twice, also with checkSelfIntersections = true. LFV-210's one-line fix alone makes this and all 9 known valid witnesses exact, with no cure triangle. Its centroid error is mostly LFV-210's (exact (1.6667, 2.0222); stock (1.5833, 1.4722); duplicate removed (1.5714, 1.6349)). With LFV-210's fix and two other Tessellator fix sketches applied, 3 of about 12 million valid lattice polygons still store a zero-area cure triangle twice (one extra entry and term, no centroid effect); all 3 hit LFV-793, where the filterPoints call after a hole merge drops a vertex copy that the next hole needs. These are search results, not a proof.
• Scale. No cure triangle occurred in the upstream geo test corpus: 411 polygons (real-world polygons from issues included), each tessellated with checkSelfIntersections off and on (822 tessellations), entered the cure step 43 times and never had a triangle cut off. That corpus is a test set, not prevalence data. Common in synthetic data: of 300,000 random hole-free rings on a 7x7 lattice, main accepts 66,208 and 5,524 of those index a triangle twice; 8.2.0, on the same seeded inputs, stores none twice (it accepts 64,940; the accepted counts differ for other reasons). Hole-free valid rings never reached it: in the exhaustive bound of 64,962,384 small lattice rings, all 1,241,798 rings with a cure triangle are JTS-invalid (self-intersecting; not all self-crossing: 12,696 self-touching rings with no proper crossing reach it too). Each cure triangle takes two nodes out of the ring, and splits and hole bridges add two node copies each, so the number of cure triangles stays linear in the polygon's size.
• Persistence. The duplicate triangle and the centroid are written at index time; documents indexed before a fix keep them until reindexed, which is harmless for searches.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: indexed triangles (expected: each distinct triangle once) expected:<3> but was:<4>
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.failNotEquals(Assert.java:835)
       org.junit.Assert.assertEquals(Assert.java:647)
       org.apache.lucene.document.TestTessellatorCureAddsTriangleTwice.testCuredTriangleIndexedOnce(TestTessellatorCureAddsTriangleTwice.java:36)

• History: a regression from a copy/paste edit. Until 8.2.0 the method ended with // Return the triangulated vertices to the tessellation and tessellation.add(new Triangle(a, node, b));. LUCENE-8620 (apache/lucene-solr#771, 62001b9b965 on master, 252421bb77c on branch_8x, 2019-09-09) added edge flags; in this method it inserted a new add above the comment and rewrote the old add below it into the same call. None of the PR's review comments touches the cure step. Instrumented 8.2.0 and 8.3.0 Tessellators cut off the same triangles, with 1 and 2 adds each.
• The algorithm it ports adds it once. The class is "inspired by mapbox's earcut algorithm" (Tessellator.java:34); earcut's cureLocalIntersections pushes the cut-off triangle once (read in the earcut source by the devil's advocate, the follow-up and the fact check, which read earcut's current src/earcut.js).
• The contract is a mesh. "Computes a triangular mesh tessellation for a given polygon" (Tessellator.java:32); numberOfTerms() returns "the number of terms (tessellated triangles) for this shape" (ShapeDocValuesField.java:84); getCentroid() "retrieves the centroid location for the geometry" (:97). Upstream TestTessellator.checkPolygon asserts that the tessellation's area equals the polygon's (TestTessellator.java:1016-1019); in the upstream geo test corpus the cure step never cuts off a triangle, and #11767 and #756 note that the method is not exercised by the tests, so no test could notice.
• The cure step exists for this input. It cuts off a triangle only where the edge before a node and the edge after the next node intersect (Tessellator.java:865-878; linesIntersect also counts some touching configurations); for hole-free rings every such case found is invalid, self-intersecting input. The default path accepts such rings, and #11767 defends the step as a best-effort clean-up of them.

The strongest case (the devil's advocate and the adjudication): the only standalone trigger is an invalid, self-intersecting ring, which the javadoc excludes ("No self intersections", Tessellator.java:45; "The polygon must not be self-crossing, otherwise may result in unexpected behavior", Polygon.java:34), and checkSelfIntersections = true rejects rings with a proper crossing such as this one; upstream tests even expect some self-crossing rings to be rejected with the flag off (TestTessellator.java:137-151, 823-861); in #11767 a maintainer proposed removing the method ("As we claim we only support valid polygons, I think it is safe to remove the method entirely"); on valid input the duplicate only doubles one of LFV-210's wrong triangles (or, with LFV-210 fixed, a zero-area one in polygons that hit LFV-793); and no search result changed in the sweeps. The strict flag does not reject every invalid ring that reaches the cure step: a self-overlapping ring POLYGON((4 4, 1 1, 4 1, 2 0, 0 1, 2 1, 4 4)) and 202 small lattice rings with no proper edge crossing, such as POLYGON((0 0, 1 1, 1 3, 0 0, 1 2, 2 0, 0 0)), are accepted with checkSelfIntersections = true and still store a triangle twice (the fact check's runs).

Why it fails as an intent argument: "unexpected behavior" leaves the region of a self-intersecting ring open, not whether the output lists one triangle twice, which is wrong under any reading (4 terms for 3 distinct triangles, and a centroid that weights one triangle twice). Nothing in the code, the history or earcut gives a reason for two adds, and the method added one from 7.5.0 to 8.2.0. What survives is impact: minor, rare in the data tested, no search change observed. Verdict: a defect, low priority.

One option was built and validated; the alternatives are noted for the discussion.

Remove Tessellator.java:890. The remaining call, under the comment "Return the triangulated vertices to the tessellation", carries the same edge flags, so nothing else changes; the other triangles of the example are unchanged. This restores the method as it was from 7.5.0 to 8.2.0 (with the flags) and as earcut has it. Add the repro class (or a TestTessellator case asserting no repeated triangle) as a regression test; upstream's checkPolygon area oracle does not apply to self-crossing rings.

         boolean caFromPolygon =
             (b.next == a) ? b.isNextEdgeFromPolygon : isEdgeFromPolygon(a, b, mortonOptimized);
-        tessellation.add(new Triangle(a, abFromPolygon, node, bcFromPolygon, b, caFromPolygon));
         // Return the triangulated vertices to the tessellation
         tessellation.add(new Triangle(a, abFromPolygon, node, bcFromPolygon, b, caFromPolygon));

Trade-offs

• None for searches: the 129,472-query sweep gives the same counts with and without the duplicate.
• Existing indexes keep the duplicate triangle and the stored centroid until reindexed; worth one CHANGES line.
• It does not fix LFV-210, which owns the valid-input trigger (a different line); fixing either leaves the other.

What the checks validated

• Gradle, scratch worktree at a9779ef3c193: on stock the 3 repro tests fail with assertions on (seed DEADBEEF) and off (5EED0792); with the fix org.apache.lucene.geo.*, org.apache.lucene.document.*Shape* and the new class pass with assertions on and off: 45 geo and shape suites (392 test cases: 366 run, 26 skipped, of which 24 nightly-only, 1 awaits-fix, 1 other), including TestTessellator (77 cases, 7 skipped), TestShapeDocValues (7), TestLatLonShape (25), TestXYShape (5) and the polygon, line, point and doc-values shape-query suites. :lucene:core:check -x test (google-java-format, ecjLint, forbiddenApis) passes. The full :lucene:core test suite was not run.
• Standalone runner: the class passes with the fix shadowed (assertions on and off); the 129,472-query sweep prints the same counts and result hash as stock.
• Earlier stages: the finder's, the independent reproducer's and the registry re-runs pass with the same deletion, as do TestTessellator, TestShapeDocValues, TestXYShape and TestLatLonShape (106 tests).

Also removes the duplicate, but changes which self-crossing rings tessellate at all: they would go straight to the split stage or be rejected. Not run; a separate decision with its own tests.

Trade-offs

A behaviour change for inputs the default path accepts today; #11767 has not settled it.

Hides the symptom for the two shape classes.

Trade-offs

Costs a set per shape and leaves Tessellator.tessellate's own output wrong for other callers.

Method: code reading inside a reachability model, witnessed by bounded search (semi-formal tier).

• The finder of a hunt unit built a probe harness on the Tessellator's monitor hook to model which inputs reach its CURE and SPLIT stages, and noticed the two identical tessellation.add calls while reading cureLocalIntersections (2026-10-27).
• Witnesses and reach came from tools: every ring with 4 or 5 vertices on 3x3 and 4x4 lattices, 6 on 4x4 and 5x5, and 7 on 4x4 (64,962,384 rings; every one that has a cure triangle is JTS-invalid, and not all are self-crossing: 12,696 self-touching rings reach it too), random JTS-valid lattice polygons with touching holes (about 4 million on stock, 12 million with the known Tessellator fixes applied), 1.3 million valid floating-point LatLon polygons, the upstream geo test corpus (411 polygons, 822 tessellations) and an exact rational area and centroid oracle. A reduction harness shrank the valid witness.
• The follow-up's history stage found this ring, which every release from 8.2.0 on accepts, with a seeded search over random hole-free rings.
• Then an independent reproducer with its own witnesses, reviews by a model from another family (OpenAI GPT-5.6, reading only), an intended-behaviour devil's advocate, an adjudication and a credibility audit.