On main, a delete push that finds nothing to freeze leaks a flush-ticket count, and NRT readers report isCurrent() == false for the rest of the writer's life

DocumentsWriterFlushQueue.addTicket raises its ticket count before it runs the supplier that freezes the buffered deletes, so that deletes being frozen still count as pending changes. When the supplier returns null because another thread has just emptied the buffer, nothing is queued, and since #15134 (b85f030c6cc, 2025-10-09) the count is not lowered again: only an exception gives it back. DocumentsWriter.anyChanges() reads that count, so from then on IndexWriter.nrtIsCurrent() is false and every NRT reader of the writer reports isCurrent() == false, also one opened right after commit(), while openIfChanged() returns null. Each refresh runs a full flush only to discard the reader. No hit, document or delete is wrong, and a new IndexWriter clears the state. Main and branch_11x only; no release has it.

1. Who asks for a push. The default flush policy calls setApplyAllDeletes() when the buffered deletes use at least the RAM buffer (FlushByRamOrCountsPolicy.java:41-48, :55-56), on every delete and after an added document once that thread's RAM growth passes a small accounting step (DocumentsWriterFlushControl.java:207-215, :238, :486-489). DocumentsWriter.applyAllDeletes (:168-186) checks the flag, isFullFlush() and deleteQueue.isOpen(); the thread that wins getAndResetApplyAllDeletes() (an atomic getAndSet(false)) calls ticketQueue.addTicket(() -> maybeFreezeGlobalBuffer(deleteQueue)) (:180).
2. Two pushes can overlap. The freeze builds the frozen packet before it clears the global buffer (DocumentsWriterDeleteQueue.java:262-273) and runs inside addTicket, which is synchronized (DocumentsWriterFlushQueue.java:38). While thread A is in there, thread B's RAM check still sees the full buffer, sets the flag again, wins it, and waits for the queue's monitor.
3. The leak. When B gets in, incTickets() runs first (DocumentsWriterFlushQueue.java:39-40, on purpose: "first inc the ticket count - freeze opens a window for #anyChanges to fail"). The supplier finds an empty buffer and returns null (DocumentsWriterDeleteQueue.java:269-276, DocumentsWriter.java:719-724). Nothing is queued and addTicket returns null (DocumentsWriterFlushQueue.java:42-47). decTickets() runs only in catch (Throwable) (:48-50) and in innerPurge, once per polled ticket (:102-105). The queue is a final field of DocumentsWriter (:96), so the extra 1 stays for the writer's life, and each further losing race adds one.
4. What reads it. hasTickets() is ticketCount.get() != 0 (DocumentsWriterFlushQueue.java:77-80); DocumentsWriter.anyChanges() includes it (:352-356), so that changes sitting in the ticket queue still count (LUCENE-3551, #4625, 2011, the comment at :345-351), and IndexWriter.nrtIsCurrent requires anyChanges() == false (IndexWriter.java:6140-6146).
5. Refresh. openIfChanged on an NRT reader goes to StandardDirectoryReader.doOpenFromWriter (:456-475): nrtIsCurrent is false, so it calls writer.getReader(...) (IndexWriter.java:516, a full flush at :586), finds the same version and returns null.
6. Other ways to a null ticket. A TLA+ model of the flush family found that a full flush can close the queue between applyAllDeletes' isOpen() check and the freeze, which then returns null for the closed queue. And flushAllThreads pushes the "naked frozen global deletes" with the same supplier (DocumentsWriter.java:691-699). The repro uses neither; the fix acts on the null result itself, so it covers all of them.
7. Not affected. commit() decides on changeCount and still skips a commit when nothing is pending (IndexWriter.java:5934-5936). hasUncommittedChanges() stays true as a side effect, but its javadoc allows a spurious true (IndexWriter.java:4218-4224), so it is not claimed on its own. The ticket-backlog check in doFlush also reads the count (DocumentsWriter.java:569-575); that was not measured.

The supplementary two-thread test, default IndexWriterConfig on a ByteBuffersDirectory: an InfoStream message hook holds the deleting thread inside its push, after 524,288 single-term deletes have buffered 18,266,984 bytes (the limit is 16,777,216); the adding thread's 20 KB document then asks for a second push and is seen BLOCKED in addTicket. A counting copy of the queue (one log line per increment and decrement, no other change) logged the same steps in all 12 runs, with the two-thread test and with the diagram probe, assertions on and off: the deleter's push 0 to 1; the adder's push, which gets null, 1 to 2 (the deleter's ticket is still queued); the adder's own segment flush 2 to 3; then the two tickets are published, 3 to 2 to 1. After both pushes main has ticket count 1 with 0 tickets queued. After commit(), DirectoryReader.open(writer) has 2 documents, openIfChanged returns null and isCurrent() is false; after 3 more rounds of addDocument, commit() and a fresh open it is still false and the count is 1 at each check. With the fix and on 10.5.2 the count is 0 and every reader is current. The hook only fixes the timing of a legal interleaving: hook-free runs reach the same state (see Who is affected).

• Who. Code built on main or branch_11x (first release 11.0.0) that indexes from several threads with deletes or updates on one writer. IndexWriter is documented as "completely thread safe, meaning multiple threads can call any of its methods, concurrently".
• What breaks. For the rest of the writer's life, isCurrent() is false for every NRT reader, including one opened right after commit(), while openIfChanged() returns null. A loop that waits for isCurrent() to turn true never ends. Every refresh (openIfChanged, SearcherManager.maybeRefresh) runs a full flush and opens a reader only to discard it.
• What does not break. No hit, document or delete is lost, wrong or exposed; nothing throws or hangs inside Lucene. The signal fails safe: it says "changed" when nothing changed, never "current" while changes are missing. A new IndexWriter starts with a clean count.
• How often. Hook-free runs on the stock jar, a new writer per round: 4 threads (2 deleting, 2 updating) at a 0.1 MB RAM buffer left 6 of 12 rounds stale (0 of 12 with the fix); an independent verifier (2 deleting, 2 adding threads) saw 6 of 10 at 0.1 MB (0 of 10 with the fix), 2 of 10 at 1 MB and 0 of 5 at the default 16 MB; with serial merges 1 of 6 rounds stayed stale after a second commit (0 of 6 with the fix); 16 threads on 2 CPUs fired it at 0.02 MB, and 16 runs with 8-16 threads at 0.05-2 MB did not. The rate at 16 MB is unmeasured.

The supplier returning null is exactly what DocumentsWriter.applyAllDeletes passes when the buffer is already empty, so the test needs no threads and no timing. The public consequence (a fresh NRT reader not current after commit()) is shown by the supplementary two-thread test described in the explanation; it is evidence, not the regression test.

Regression test: this same test. It passes with the fix and can go in a new TestDocumentsWriterFlushQueue (none exists upstream) or as a method in TestDocumentsWriterDeleteQueue. The bare AssertionError comes from the assertFalse without a message; a message can be added without changing the result.

cp $REPRO/TestDocumentsWriterFlushQueue.java $LUCENE/lucene/core/src/test/org/apache/lucene/index/
cd $LUCENE && ./gradlew :lucene:core:test --tests TestDocumentsWriterFlushQueue -Ptests.seed=DEADBEEF
# the same result with -Ptests.asserts=false

# gradle, stock 645d4fe14a20, -Ptests.seed=DEADBEEF (assertions on; the same with -Ptests.asserts=false)
TestDocumentsWriterFlushQueue > testNullTicketDoesNotLeaveTicketCount FAILED
    java.lang.AssertionError
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:205223864E05044B]:0)
        at org.junit.Assert.fail(Assert.java:87)
        at org.junit.Assert.assertTrue(Assert.java:42)
        at org.junit.Assert.assertFalse(Assert.java:65)
        at org.junit.Assert.assertFalse(Assert.java:75)
        at org.apache.lucene.index.TestDocumentsWriterFlushQueue.testNullTicketDoesNotLeaveTicketCount(TestDocumentsWriterFlushQueue.java:27)

# with the fix: 1 test, 0 failures (assertions on and off)

# supplementary two-thread test on stock main (evidence, not the repro)
TestNrtReaderStaysStaleAfterRacingDeleteFreeze > testFreshNrtReaderIsCurrentAfterRacingDeletePush FAILED
    java.lang.AssertionError: a fresh NRT reader must be current

• The contract. DirectoryReader.java:631-638: for an NRT reader, isCurrent() "checks if either a new commit has occurred, or any new uncommitted changes have taken place via the writer. Note that even if the writer has only performed merging, this method will still return false." The upstream test TestIndexWriterReader.testIsCurrent asserts isCurrent() for fresh NRT readers.
• A null ticket is designed. The freeze already returned null for an empty buffer before 2019, and addDeletes then queued a ticket with no updates, so the count matched the queue. LUCENE-8813 (165d2d5ff531, 2019, 8.2.0) added a null result for a closed queue and made addDeletes queue no ticket when the freeze returns null (closed queue or empty buffer), leaving success false so the count was given back; #12647 (268dd54a869, 9.9.0) introduced addTicket(Supplier) and kept that. applyAllDeletes tests the result for != null, and addTicket says "no need to publish anything if we don't have any frozen updates".
• The change was a mechanical cleanup. #15134 ("Remove even more boolean success flags") changed 15 files, is labelled skip-changelog, and has no review comment on this file. Its diff replaces finally { if (!success) decTickets(); }, where success was set only when a ticket was queued, with catch (Throwable t) { decTickets(); throw t; }. Its parent c67f8d38641 passes both tests; b85f030c6cc fails both.
• Why the count exists. LUCENE-3551 (#4625, 2011) added hasTickets() to anyChanges() (DocumentsWriter.java:345-351), so that changes sitting in the ticket queue still count. A count with no ticket behind it is the opposite of that design.

The strongest case: Lucene already accepts a spurious isCurrent() == false. TestIndexWriterReader.testReopenAfterNoRealChange asserts isCurrent() == false and then openIfChanged() == null after a delete that matches nothing. LUCENE-3581 (#4655, open since 2011) asks to remove that conservatism, and Michael McCandless commented there in 2012: "We are returning \"false\" when we could return \"true\" from isCurrent, but this just means the app will go through the reopen when it didn't have to...? Ie relatively minor?". And hasUncommittedChanges() is documented as allowed to be true with no real change.

Why it fails: every accepted case is transient, because the next reopen applies the pending delete and the reader is current again. Here nothing is pending, the count is never given back, and the false survives commit(), forceMerge(1) and every later reader. That supports a low impact, not "intended". No single-thread trigger was found: deleteDocuments(new Term[0]) followed by commit() does not leak. Verdict: a regression, not intended.

One option was validated in a scratch worktree of 645d4fe14a20; the second is equivalent; the third is a trap to avoid.

One file, +2 lines. Keeps #15134's cleanup (no success flag) and the early incTickets() that guards the freeze window.

      if (ticket != null) {
        // no need to publish anything if we don't have any frozen updates
        queue.add(ticket);
      } else {
        decTickets();
      }
      return ticket;

Trade-offs

None found. The count is still raised during the freeze, so anyChanges() cannot miss deletes that are being frozen.

What the checks validated

• Stock: the minimal test fails with assertions on and off.
• With the fix: the minimal test and the two-thread test pass with assertions on and off (the assertions-off step was re-run because its first attempt stopped before any test ran).
• Closest suites with the fix: TestIndexWriterReader (incl. testIsCurrent and testReopenAfterNoRealChange), TestIndexWriter, TestIndexWriterDelete, TestDocumentsWriterDeleteQueue, TestFlushByRamOrCountsPolicy, TestIndexWriterExceptions, TestIndexWriterExceptions2, TestIndexWriterThreadsToSegments: 8 classes, 226 tests, 0 failures, 12 skipped.
• :lucene:core:checkGoogleJavaFormat, ecjLintMain and forbiddenApisMain pass.
• Not run: nightly tests, benchmarks.

Put boolean success and finally { if (!success) decTickets(); } back, as at c67f8d38641. Main with the parent's DocumentsWriterFlushQueue.java passes the two-thread test.

Trade-offs

Same behaviour as the recommended fix, but it undoes part of the #15134 cleanup.

Moving incTickets() after queue.add(ticket) also stops the leak.

Trade-offs

It reopens the window the comment on incTickets() guards: the freeze clears the global buffer before the ticket is queued, so anyChanges() could report no changes while frozen deletes are in flight, the unsafe direction ("current" while changes are missing).

Method: code reading, then executed checks (the study's "non-formal" tier). A hunt over sites where state is read before a lock is taken and acted on after it listed DocumentsWriter.applyAllDeletes: its preconditions (an open, non-empty delete buffer) can be gone when the freeze runs, so the supplier returns null. Following that null into DocumentsWriterFlushQueue.addTicket showed the count is never given back.

• Bounded-exhaustive translation validation: the real DocumentsWriterFlushQueue against an independent counter model, over all 55,987 operation sequences of length up to 6 (null supplier, deletes ticket, segment ticket, mark failed, purge, throwing supplier): 36,456 mismatching on main, exactly the sequences with a null supplier, and 0 with the fix and on 10.5.2.
• Hook-free runs on the stock jar: stale in 6 of 12 rounds at a 0.1 MB RAM buffer, 0 of 12 with the fix.
• A deterministic two-thread JUnit on the public API (an InfoStream message hook fixes the timing), then the one-line minimal test.
• A second hunt, a TLA+ model of the flush family, later found the same root (invariant TicketCountExact, through the closed-queue null) and handed its evidence over.