SearcherLifetimeManager.prune sorts searchers by first-record time, so PruneByAge can drop the current searcher

SearcherLifetimeManager keeps older searchers open so that a follow-up request (the next page) can reuse the searcher of the first request through the token record() returns. prune(Pruner) is documented to pass the searchers newest to oldest, each with its age, the time since it was the current searcher, and PruneByAge drops only searchers older than the newest by more than maxAge. The code instead sorts by the time each reader version was first recorded. When a request records an older searcher for the first time after another request has recorded the refreshed one, prune takes the older searcher for the newest (age 0) and ages the current searcher from that late record. PruneByAge then drops the current searcher, even right after record() returned a token for it, and keeps the older one. The effect is small and recoverable: acquire(token) returns the documented "session timed out" null until the next record() adds the searcher back, the older reader stays open longer than maxAge, and a count-based pruner keeps the wrong searcher. No search result is wrong. It dates from 3.5.0, when the class was added, and every release tried since then fails.

1. The sort key is the first-record time. SearcherTracker stores recordTimeSec = System.nanoTime() / NANOS_PER_SEC in its constructor (SearcherLifetimeManager.java:97-104), and compareTo is Double.compare(other.recordTimeSec, recordTimeSec) under the comment "Newer searchers are sort before older ones" (:106-110).
2. It is set once per reader version. record() looks the tracker up by reader version and creates one only if none exists (:146-155); a later record() of the same searcher returns the same token and changes nothing (:156-164). Its javadoc invites repeated calls: "Always call this when you've obtained a possibly new IndexSearcher ... It's fine if you already passed the same searcher to this method before" (:132-134).
3. Ages come from the sorted neighbour. prune copies and sorts the trackers (:239-243), gives the first age 0 (:248-249) and each later one now - lastRecordTimeSec, the record time of the tracker before it in that order (:251, :263), as the comment says: "First tracker is always age 0.0 sec, since it's still 'live'; second tracker's age (= seconds since it was 'live') is now minus first tracker's recordTime" (:253-256).
4. What goes wrong. Record S2 at t0, then the older S1 for the first time at t1 > t0. The sorted list is [S1, S2]: S1 gets age 0, S2 gets now - t1. PruneByAge returns ageSec > maxAgeSec (:222-224), so S2 is removed and its reader released (:257-262) once now - t1 > maxAge; acquire(version) then finds no tracker and returns null (:177-185).
5. Why it heals. The token is the reader version (:164). While S2 is SearcherManager's current searcher its reader stays open, so the next record(S2) creates a new tracker with a fresh record time, which sorts first, and old tokens for S2 resolve again; S1 is then aged from that re-record.

• Minimal test, no sleep: record S2, record S1, record S2 again for a token, prune(new PruneByAge(0)) (which must keep the newest searcher): acquire(token) is null. Fails 1/1 with -ea, 10/10 and 20/20 with -da on main; also on 10.6.0 and 9.12.3.
• First repro: 250 ms after A's late record of S1, request C records S2 and prune(new PruneByAge(0.1)) drops it.
• Impact demo: 1.5 s after the two records, prune(new PruneByAge(1.0)): acquire(token of S2) is null while acquire(token of S1) returns the older searcher; with the fix it is the other way round.
• Bounded-exhaustive test of the real classes over all 8,892 operation sequences of length up to 10: 520 order mismatches and 380 cases where the newest recorded searcher was pruned on stock, all and only in sequences with a late first record; 0 with the fix.
• With the javadoc's PruneByAge(600.0) the same path drops S2 once 600 s have passed since the late record, whether or not a newer searcher is first recorded in the meantime; if none is, S2 is still the current searcher when it is dropped (by reading the code; the runs above are that path scaled down).

• Who. Applications that opt into SearcherLifetimeManager (@lucene.experimental) with the javadoc's per-request acquire-then-record pattern and a time- or count-based Pruner, where one request's acquire-to-record window can span a refresh plus another request's record() of the refreshed searcher, for a searcher no request recorded while it was current. This is a legal variation of the javadoc's acquire-then-record pattern: any delay between acquire() and record() (for example recording after running the query) opens the window, and frequent NRT refreshes with light traffic make it likelier.
• What goes wrong. Follow-up requests on the current searcher get acquire(token) == null, the documented "session timed out" outcome, until the next record() adds it back, so the user sees a spurious timeout or the application restarts the search. The older reader stays open longer than maxAge: it is dropped only maxAge after a newer searcher gets a new tracker (for example the re-record of S2), and nothing in the class bounds how long that takes. A count-based Pruner ("keep the newest N", the use the design review discussed) keeps S1 and drops S2.
• Not hit. Lucene returns no wrong hit, count or score, nothing is corrupted and nothing throws (what the application does after a null from acquire() is up to it). Applications that give every searcher its first record from one refresh path (the initial searcher before requests start, then each new searcher right after maybeRefresh(), as ShardSearchingTestBase does) avoid the trigger: a request's later record() then finds the existing tracker and changes nothing, unless that searcher has already been pruned.
• Default vs opt-in, scale. Opt-in API; no special codec or settings; two searchers and one document are enough. Same failure with assertions on and off.
• How likely. Rare: it needs the out-of-order first record and, for the current searcher to be dropped, no newer searcher first recorded within maxAge afterwards. The saved searches found no public report.

• Deterministic. Each record() of a new version reads System.nanoTime(), so S1's record time is later than S2's, and S2's computed age is positive, whenever the clock advances between the calls, which it did in every run; PruneByAge(0) drops any searcher with age > 0. A correct implementation gives the newest searcher age 0 and keeps it. It failed 10 of 10 with --iters 10; the seeds DEADBEEF and 5EED1066 fail the same way through gradle. nanoTime() only promises values that do not decrease: on a clock so coarse that both records read the same value the test could pass on stock, but it cannot fail on a correct implementation.
• PruneByAge(0) is legal. The constructor rejects only negative values; with 0 it keeps exactly the searchers whose computed age is 0; a correct implementation gives that age to the newest searcher, so the newest must survive. The study's first repro used a 250 ms sleep against PruneByAge(0.1) and fails the same way; it is supplementary evidence only.
• The test is the study's minimal test with its one comment reworded onto two lines, so that it passes Lucene's checkGoogleJavaFormat; the code is unchanged, and the assertion moved from line 41 to line 42.
• Resources. There is no try/finally, so a failing run leaves its readers and the IndexWriter open. With the documented seeds the run reports only the one AssertionError. When newDirectory() picks a file-system directory (rare outside nightly runs; seen in one of ten iterations with seed 1066FAC7, and with seed DEADBEEF when the directory is forced to MMapDirectory) it also reports a suite-level "file handle leaks" failure for write.lock. With a fix it passes and closes everything. As a regression test, use this same test.

cp $REPRO/TestSearcherLifetimeManagerPruneOrder.java $LUCENE/lucene/core/src/test/org/apache/lucene/search/
cd $LUCENE
./gradlew :lucene:core:test --tests org.apache.lucene.search.TestSearcherLifetimeManagerPruneOrder -Ptests.seed=DEADBEEF -Ptests.asserts=true
# assertions off: -Ptests.asserts=false (same failure)

# stock main 645d4fe14a20, gradle, seed DEADBEEF, assertions on (off: same failure)
TestSearcherLifetimeManagerPruneOrder > testPruneKeepsCurrentSearcher FAILED
    java.lang.AssertionError
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:C4B4FADBD819493]:0)
        at org.junit.Assert.fail(Assert.java:87)
        at org.junit.Assert.assertTrue(Assert.java:42)
        at org.junit.Assert.assertNotNull(Assert.java:713)
        at org.junit.Assert.assertNotNull(Assert.java:723)
        at org.apache.lucene.search.TestSearcherLifetimeManagerPruneOrder.testPruneKeepsCurrentSearcher(TestSearcherLifetimeManagerPruneOrder.java:42)
:lucene:core:test (FAILURE): 1 test, 1  failure

# with the recommended fix (repro + TestSearcherManager + TestShardSearching, which is @Nightly and skipped here)
:lucene:core:test (SUCCESS): 14 tests, 1 skipped
# TestShardSearching with -Ptests.nightly=true
:lucene:core:test (SUCCESS): 1 test

• prune: "The entries are passed to the Pruner in sorted (newest to oldest IndexSearcher) order" (SearcherLifetimeManager.java:228-229).
• Pruner.doPrune: "@param ageSec how much time has passed since this searcher was the current (live) searcher" (:201). S2 is still current yet gets a positive age; S1, which S2 replaced, gets 0.
• PruneByAge: "drops any searcher older by more than the specified seconds, than the newest searcher" (:208-209). The code comment: "First tracker is always age 0.0 sec, since it's still 'live'" (:253-256).
• LUCENE-3639 (#4713, 3.6.0). Michael McCandless wrote that the patch makes it "compute age by how long ago the searcher was replaced with a new searcher (not how long ago the searcher was first enrolled)"; lucene/CHANGES.txt says the same ("compute age to be how long ago the searcher was replaced with a new searcher"). The sort by first-record time stayed.
• The design review relied on the order. On LUCENE-3486 (#4560), Shai Erera noted that a "newest 5 searchers" pruner can count doPrune() calls "because prune(Pruner) guarantees that the searchers are passed newest to oldest".
• No call-order precondition. Neither the class javadoc nor record() asks callers to record searchers in the order they were opened, and record() is safe to call from concurrent threads (putIfAbsent, "Another thread beat us", :151-155).
• Tests. TestSearcherManager uses the acquire-then-record pattern from search threads beside a reopen thread but accepts a null and never asserts which searcher is pruned; ShardSearchingTestBase records each node's initial searcher at startup and each new searcher in the reopen thread, which avoids the trigger. No test pins the record-time order.

The case for intended (made by an executing reviewer from another model family, OpenAI GPT-5.6): record() is the session's recency event; the order has been by record time since 3.5.0, whose javadoc defined age as "how long ago this searcher was recorded vs the most recently recorded searcher"; a null from acquire() is documented; the class is experimental; and pure version order would expire at once a token just returned by the late first record of an older searcher.

Why it fails. (1) LUCENE-3639 replaced the 3.5 wording on purpose with "since this searcher was the current (live) searcher" and "not how long ago the searcher was first enrolled". (2) In the repro S2 is the newest under every reading: highest version, still current, and the most recently recorded (request C records it after A records S1). Stock keeps S2 only if "newest" means "first recorded most recently", the reading the author rejected. (3) The documented null is for searchers that "timed out", and PruneByAge limits that to searchers older than the newest. (4) The token-window point is about a fix, not the bug; the recommended fix keeps that window. The other cross-model lenses, independent verifiers and the adjudication called it real.

All options sort by reader version, newest first; they differ in how they age the searchers after the first. This relies on the reader versions of one index growing with every change, which DirectoryReader.getVersion documents ("This version is advanced every time a change is made with IndexWriter"); the class's version keys only need versions to be unique. So the fixes assume that one SearcherLifetimeManager serves the searchers of one index (for example from one SearcherManager). Option C was applied in a scratch worktree of main 645d4fe14a20 and run with gradle; A and B were checked by the study's standalone runs, TLA+ model and bounded-exhaustive test. Which age policy to adopt for a late first-recorded older searcher is the maintainers' call; the claim holds under all three. Workaround today: give every searcher its first record from one refresh path, the initial searcher before requests start and each new searcher right after maybeRefresh(), with all refreshes on that thread (as ShardSearchingTestBase does).

compareTo becomes Long.compare(other.version, version). In prune, each later searcher's age is now - max(earliest record time of the newer searchers already passed, its own record time). The running minimum ages an older searcher from the earliest first record of any newer searcher, the earliest time the class can see that it had been replaced (it sees only first-record times). The max keeps stock's full maxAge window for a token returned by an older searcher's first record.

diff --git a/lucene/core/src/java/org/apache/lucene/search/SearcherLifetimeManager.java b/lucene/core/src/java/org/apache/lucene/search/SearcherLifetimeManager.java
index d7a7589e5b0..1bff3d9363c 100644
--- a/lucene/core/src/java/org/apache/lucene/search/SearcherLifetimeManager.java
+++ b/lucene/core/src/java/org/apache/lucene/search/SearcherLifetimeManager.java
@@ -103,10 +103,11 @@ public class SearcherLifetimeManager implements Closeable {
       recordTimeSec = System.nanoTime() / NANOS_PER_SEC;
     }
 
-    // Newer searchers are sort before older ones:
+    // Newer searchers (higher reader version) sort before older ones, whatever the order in
+    // which they were first recorded:
     @Override
     public int compareTo(SearcherTracker other) {
-      return Double.compare(other.recordTimeSec, recordTimeSec);
+      return Long.compare(other.version, version);
     }
 
     @Override
@@ -241,14 +242,18 @@ public class SearcherLifetimeManager implements Closeable {
       trackers.add(tracker);
     }
     Collections.sort(trackers);
-    double lastRecordTimeSec = 0.0;
+    // earliest record time of any newer searcher: this searcher has not been the current one
+    // since then
+    double newerRecordTimeSec = Double.NaN;
     final double now = System.nanoTime() / NANOS_PER_SEC;
     for (SearcherTracker tracker : trackers) {
       final double ageSec;
-      if (lastRecordTimeSec == 0.0) {
+      if (Double.isNaN(newerRecordTimeSec)) {
         ageSec = 0.0;
       } else {
-        ageSec = now - lastRecordTimeSec;
+        // a searcher first recorded after a newer one still gets a full window from its own
+        // record, so the token that record returned does not expire at once
+        ageSec = now - Math.max(newerRecordTimeSec, tracker.recordTimeSec);
       }
       // First tracker is always age 0.0 sec, since it's
       // still "live"; second tracker's age (= seconds since
@@ -260,7 +265,10 @@ public class SearcherLifetimeManager implements Closeable {
         searchers.remove(tracker.version);
         tracker.close();
       }
-      lastRecordTimeSec = tracker.recordTimeSec;
+      newerRecordTimeSec =
+          Double.isNaN(newerRecordTimeSec)
+              ? tracker.recordTimeSec
+              : Math.min(newerRecordTimeSec, tracker.recordTimeSec);
     }
   }
 

Trade-offs

An older searcher first recorded late lives up to maxAge after its own record, not after it was replaced. The old comment "now minus first tracker's recordTime" (:253-256) would need updating; the diff leaves it as is. The root-cause reviewer's coupled case (a newer searcher recorded late between two others) is covered only when the older searcher was first recorded before the newer ones: the reviewer's three-searcher test, whose two older searchers are first recorded 300 ms after the newest, fails with C by design and passes with B. The minimal test covers only the two-searcher order bug; if the running minimum stays, a three-searcher test would pin it.

What the checks validated

Gradle, scratch worktree of 645d4fe14a20, JDK 25 (2026-11-02): the minimal test passes with assertions on (seed DEADBEEF) and off (seed 5EED1066); TestSearcherManager 12/12 in both runs; TestShardSearching passes with -Ptests.nightly=true; checkGoogleJavaFormat, ecjLintMain and ecjLintTest pass. Without the fix the same worktree fails the test. The study: standalone repro 1/1 -ea, 20/20 -da; TLA+ NewestFirst, LiveKept, TokenWindow and RetentionBoundOwn hold (76,854 states; the model assumes that each record() reads a strictly later clock value); 0 mismatches over 8,892 operation sequences.

Change compareTo to Long.compare(other.version, version) and keep the age loop. One line; fixes the order and never drops the newest searcher.

-      return Double.compare(other.recordTimeSec, recordTimeSec);
+      return Long.compare(other.version, version);

Trade-offs

Ages a late first-recorded older searcher from the newer searcher's earlier record, so the token record() has just returned for it can expire at the next prune; the pairwise "previous tracker" age can keep an older reader too long when a newer one was recorded late between two others.

What the checks validated

Study only: the independent reproducer's own test passes with exactly this change; TLA+ NewestFirst and LiveKept hold, TokenWindow and RetentionBound are violated.

Each older searcher is aged from the earliest first record of a newer one, the closest the class gets to "time since replaced".

Trade-offs

Like A, it can expire at once a token just returned by an older searcher's first record (the intended-lens reviewer's control fails).

What the checks validated

Study only: 0 mismatches over 8,892 operation sequences; TLA+ NewestFirst, LiveKept and RetentionBound hold, TokenWindow is violated; the root-cause reviewer's three-searcher test passes.

• Lead. A unit that explored preemptions and refresh faults in the NRT reference managers, next to a TLA+ model of LiveFieldValues and the reopen thread, drove SearcherLifetimeManager record/prune in its workload and held this back as a Low lead with a one-test public-API JUnit that fails on stock main (2026-10-29). Whether the first signal came from that work or from reading the code while writing the workload is not recorded, so the method could also be called non-formal.
• Adjudication unit. Re-ran the lead, reduced it to the current-searcher token scenario, model-checked record/prune in TLA+ (TLC: stock violates NewestFirst, LiveKept and RetentionBound; the fix satisfies NewestFirst, LiveKept, TokenWindow and RetentionBoundOwn, 76,854 states, vacuity probes reached) and ran a bounded-exhaustive model-based test of the real SearcherManager and SearcherLifetimeManager over all 8,892 operation sequences of length up to 10 (520 order and 380 live-searcher mismatches on stock, all and only in sequences with a late first record; 0 with the fix).
• Verification. Executing cross-model reviews (OpenAI GPT-5.6: intended, root-cause and refute lenses), an independent reproducer, an intended-behaviour devil's advocate, an adjudication and a credibility audit.