The Lucene 10.6.0 release notes credit the CheckIndex .si change to GITHUB#17820, an issue that does not exist, instead of GITHUB#7820

The 10.6.0 Improvements entry reads "* GITHUB#17820: CheckIndex now reports which segment's .si file could not be read, rather than only that a commit point was unreadable. SegmentInfos throws CorruptSegmentInfoException, carrying the segment name and the underlying failure, when a .si file is missing or corrupt; other I/O failures, such as transient ones, propagate unchanged. (Gokul Manoj, Serhiy Bzhezytskyy, Alex Reelsen)". The change belongs to issue #7820 (open, "CheckIndex cannot "fix" indexes that have individual segments with missing or corrupt .si files because sanity checks will fail trying to read the index initially. [LUCENE-6762]"): the feature commit, CheckIndex.java, TestCheckIndex and main's copy of the entry all name 7820. Issue 17820 does not exist, so the link on the published 10.6.0 Changes page returns 404. The extra digit came in on 2026-10-22 with the direct-push backports of #16788 to branch_10x and branch_10_6, which rewrote the entry to add #16788's wording; main's commit of the same PR kept 7820. It is a documentation defect with no code, index or search effect. The fix is a one-character edit on branch_10_6, ideally before the release-time CHANGES sync, a manual edit in which the release manager copies the 10.6.0 section back to main.

• At the 10.6.0 tag, CHANGES.txt:6 is the Lucene 10.6.0 heading and CHANGES.txt:112 starts the entry: * GITHUB#17820: CheckIndex now reports which segment's .si file could not be read, rather than only that. The published 10.6.0 Changes page, line 293, links it to the GitHub issue page for 17820 (HTTP 404) and has no link to issues/7820. The page is byte-identical to the staged RC1 page (same sha256).

• The feature commit f30bd1b9b4f: "GITHUB#7820: report which segment's .si could not be read (#16476)"; its CHANGES hunk adds * GITHUB#7820:.
• CheckIndex.java:639 on main (:603 at 10.6.0): // https://github.com/apache/lucene/issues/7820: also attempt to open any older commit; TestCheckIndex.java:249 (:255 at 10.6.0) cites the same issue.
• Main's copy of the entry, CHANGES.txt:562 at 645d4fe14a20: * GITHUB#7820: .... Main's commit of #16788 itself, 330ee57b167, kept * GITHUB#7820:.

1. 2026-10-05: #16476 adds the entry on main and on branch_10x (f30bd1b9b4f, 6758e9c3c5c) as GITHUB#7820. 2026-10-14: branch_10_6 is cut and inherits it.
2. 2026-10-21: #16788 (by spinscale; merged by romseygeek per the PR's GitHub record) extends the wording on main and keeps 7820. 2026-10-22: the changelog sync 7cecf795236 copies branch_10_6's text of that moment (older wording, 7820) into main's 10.6.0 section.
3. 2026-10-22: the direct-push backports of #16788 to branch_10x (081f0abb6e3) and branch_10_6 (1b61ada0305) change -* GITHUB#7820: to +* GITHUB#17820: in the same hunk that adds the #16788 wording and credit. git log -S'GITHUB#17820' on branch_10_6 finds only 1b61ada0305.
4. 2026-10-26: RC1 4ae946e5a9b, released as 10.6.0 on 2026-10-29. changes2html.pl:28, 574-576 turns the number into the dead link; neither it nor the checks the verifiers inspected (the disabled changelog workflow, smokeTestRelease.py) validate link targets.

• Who meets it: readers of the 10.6.0 notes (CHANGES.txt in the source release, the published 10.6.0 Changes page) who follow this one entry's issue link. It is not tied to any setting or API.
• What they get: a 404 when they follow the link, a routine way to learn more about a change. The entry text and CheckIndex.java still lead to #7820, so the cost is a detour.
• What does not happen: no effect on code, indexes, queries or results.
• Scale: one line in one release line (10.6.x). Unfixed, it stays in branch_10_6's retained 10.6.0 section (already below the new 10.6.1 section), so later 10.6.x CHANGES files would repeat it. Main has the right number. The release wizard's "Synchronize CHANGES.txt" step asks the release manager to copy the released section back to main (releaseWizard.yaml:1399-1404); it is a manual edit in an editor followed by a "Sync CHANGES" commit (:1424-1443), not a mechanical copy. Main has had no such commit for 10.6.0 yet, so main's 7820 could become 17820 if the section is copied as it is; the release manager may equally reconcile it by hand (an inference from the documented step).
• Projection, not an observation: once the tracker reaches 17820 the link would point to an unrelated item; the tracker is at #16959.
• How much it matters. For it: readers who follow the published link get a 404, the fix is one character, and Lucene has merged this kind of fix before. Against it: main is already right, a branch_10_6 edit cannot repair the published 10.6.0 files, and the entry text and CheckIndex.java still lead to #7820. Whether a dead link counts as user impact is a judgement call, not a demonstrated software defect.

No Lucene API is involved; the package only keeps the file next to TestCheckIndex, and the result does not depend on the seed or on assertions. The test does not use the network, so it checks the number, not the 404. -Ptests.jvmargs passes the path to the forked test JVM; it replaces gradle's default extra test JVM flags, which does not matter here. The file has no Apache license header.

The simplest demonstration needs no test: git show releases/lucene/10.6.0:lucene/CHANGES.txt | grep -n 'GITHUB#17820' prints line 112, and the GitHub issue page for 17820 is a 404.

No regression test is suggested. The fix is a text edit, and a test that reads CHANGES.txt and pins one entry is not something Lucene's suite does; this test is evidence only.

cd $LUCENE && git checkout releases/lucene/10.6.0      # or branch_10_6
cp $REPRO/TestChangesCheckIndexEntryIssue.java lucene/core/src/test/org/apache/lucene/index/
./gradlew :lucene:core:test --tests org.apache.lucene.index.TestChangesCheckIndexEntryIssue -Ptests.seed=DEADBEEF -Ptests.asserts=true "-Ptests.jvmargs=-Dchanges.txt=$PWD/lucene/CHANGES.txt"
# same failure with -Ptests.asserts=false

# gradle on a worktree of releases/lucene/10.6.0 (4ae946e5a9b), seed DEADBEEF, -Ptests.asserts=true (identical with false)
> Task :lucene:core:test FAILED
TestChangesCheckIndexEntryIssue > testCheckIndexEntryCitesIssue7820 FAILED
    org.junit.ComparisonFailure: expected:<GITHUB#[]7820> but was:<GITHUB#[1]7820>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:208B4075A96A5DCB]:0)
        at app//org.junit.Assert.assertEquals(Assert.java:117)
        at app//org.junit.Assert.assertEquals(Assert.java:146)
        at app//org.apache.lucene.index.TestChangesCheckIndexEntryIssue.testCheckIndexEntryCitesIssue7820(TestChangesCheckIndexEntryIssue.java:16)
:lucene:core:test (FAILURE): 1 test, 1  failure
BUILD FAILED

# a separate re-run on the jars (no gradle), seed DEADBEEF
# released 10.6.0 jars + the 10.6.0 tag's CHANGES.txt (line 112): FAIL tests_run=1 failures=1, -ea and -da, same message
# main 645d4fe14a20 jars + main's CHANGES.txt (line 562): PASS, -ea and -da
# main jars + today's branch_10_6 text (91eaab4fb29, line 119): FAIL; + today's main text (f815e679bf6, line 593): PASS

# the published 10.6.0 Changes page, line 293 (fetched 2026-11-01; the link target is given in words)
<li><a href="[the GitHub issue page for 17820]">GITHUB#17820</a>: CheckIndex now reports which segment's .si file could not be read, rather than only that
# the GitHub issue page for 17820 -> HTTP 404; https://github.com/apache/lucene/issues/7820 -> HTTP 200

• The convention. CONTRIBUTING.md:107 (10.6.0: line 101): "A CHANGES entry should start with the issue or pull request number GITHUB#XXX that is followed by the description of the change and contributors' name."
• Main and the branch are meant to agree. dev-tools/scripts/diff_lucene_changes.py:24-29: "It's best to keep these 1) identical and 2) matching what changes were actually backported to be honest to users".
• Most likely an accidental extra digit (an inference; nothing records why). The backport hunk changes the number next to the intended wording change, the commit message does not mention renumbering, and no comment on #16788, #16476, #7820 or the backport commits mentions 17820.
• Precedent. 18a71043c80 "Fix up PR number in changes entry for #16428" (2026-08-03, GITHUB#16408 -> GITHUB#16428); 51ade888f32 "Update wrong PR number in CHANGES.txt" (2023-09-19, GITHUB#2472 -> GITHUB#12472) and its siblings ac62c58d46c, f5d5dc289ed; 367cd2ea95b "Associate correct PR with DrillSideway change in CHANGES" (2022).

Strongest case for leaving it (the intended-behaviour devil's advocate): CHANGES is curated prose that the release manager reworks into the release notes (the wizard's draft-release-notes step says to edit its contents "into a more concise format for public consumption", releaseWizard.yaml:606; that step writes the wiki release notes and does not edit CHANGES.txt); CONTRIBUTING only says "should"; a wrong link is no reason to respin a release; and main's wording differs anyway, so the entry is in flux until the release sync.

Why it fails: each point is about severity or process, not intent. Nothing in code, tests, PRs or lists treats 17820 as meaningful, the published 10.6.0 page links a 404, and the project has corrected exactly this kind of slip before. The fix is a text edit, not a respin. An independent reviewer from another model family (OpenAI GPT-5.6, reading only) rated the 'intended' argument weak; the earlier refute review (reading only, so it could not run code) returned a procedural "not real" (it expected a failure on main, which is correctly unaffected) and it called the release text "a genuine, minor documentation typo".

One CHANGES.txt edit on branch_10_6. Main already has the right number; branch_10x needs nothing (decommissioned on 2026-10-29, #16911). The released 10.6.0 files and the published 10.6.0 page keep the dead link; whether to republish the page is the committers' call. The sibling LFV-948 (the 10.6.0 StableTflSimilarity entry advertises k3) is another 10.6.0 CHANGES defect.

Line 119 on today's branch_10_6 head 91eaab4fb29 (line 112 at the 10.6.0 tag; the new 10.6.1 section moved it down by 7 lines).

@@ -116,7 +116,7 @@
 * GITHUB#16091: Replace deprecated IndexSearcher#search(Query, Collector) usage with CollectorManager
   in JoinUtil#createJoinQuery for the GlobalOrdinalsCollector case. (Luca Cavanna)
 
-* GITHUB#17820: CheckIndex now reports which segment's .si file could not be read, rather than only that
+* GITHUB#7820: CheckIndex now reports which segment's .si file could not be read, rather than only that
   a commit point was unreadable. SegmentInfos throws CorruptSegmentInfoException, carrying the segment
   name and the underlying failure, when a .si file is missing or corrupt; other I/O failures, such as
   transient ones, propagate unchanged. (Gokul Manoj, Serhiy Bzhezytskyy, Alex Reelsen)

Trade-offs

None in code. Doing it before the release-time "Synchronize CHANGES.txt" step means a release manager who copies the section back to main copies the right number; the step is a manual edit, so inspect the sync diff either way.

What the checks validated

In a scratch worktree of the 10.6.0 tag (main already has the right number, so the fix has nothing to change there), OpenJDK 25.0.3: the diff applies and no GITHUB#17820 is left; the minimal test fails before and passes after, and TestCheckIndex passes (1 + 9 tests, -Ptests.asserts=true and false; a text edit cannot affect it, so this only shows nothing breaks); ./gradlew :lucene:documentation:changesToHtml renders line 293 as a link to issues/7820 with no issues/17820 left; the diff applies to today's branch_10_6 text with a 7-line offset (patch --dry-run).

Alongside the fix, replace main's older wording of the entry (CHANGES.txt:562-564 at 645d4fe14a20) with the released wording, keeping GITHUB#7820: what the release-time sync should produce.

Trade-offs

That step belongs to the release manager; doing it with the fix only makes main match branch_10_6 earlier.

• Tracker check (a hunt unit): every GITHUB# number of the RC's 10.6.0 section (110 distinct, 112 occurrences) was looked up through the GitHub issues API and its title compared with the entry; 109 match, 17820 is a 404.
• Offline check: no number may be newer than every issue or PR the release branch's commit subjects name (max #16910 on the RC branch); it fails on the RC text and passes on main's text and on the fixed text. Its known limit: it false-fails on 9.12.3, whose commit subjects omit a valid number.
• Verification: an independent reproducer with its own oracle (tracker maximum, and the entry), an independent reviewer from another model family (OpenAI GPT-5.6) and an intended-behaviour devil's advocate all called it real; an adjudication confirmed it (high). The repro was then reduced to one test with one assertion.