Skip to content

Conversation

@ohadzeliger
Copy link
Contributor

@ohadzeliger ohadzeliger commented Oct 30, 2025

The issue at hand is that when running multiple update operations in a single transaction, the partition's document counts and the PK-segment index may get into an inconsistent state. The root cause is that the first update in the transaction clears the doc from the Lucene index and the PK index. Since the changes are not flushed, the IndexWriter has them cached in the NRT cache. The second record update would then not find the record in the PK index (because the segment has changed but the IndexReader does not yet reflect that) and therefore the delete is skipped, including updating the partition count. Note that it does attempt a delete-by-query that actually removes the doc from the Lucene index, but since we can't know that, the partition is not updated.
The proposed solution is as follows:

  • Add a forceDelete flag to the LuceneIndexMaintainer.tryDelete method, set to true when we are doing update. The rationale is that when doing update we know that the old document actually existed, even if we can't find it
  • For the PK index, in case of forceDelete, clear the entire range for the record PK, removing the record entry regardless of the segment it is currently in
  • For the partitioner, in case of forceDelete , always try to decrement the count since we assume that update always has an original record that is being modified

Resolve #3704

@ohadzeliger ohadzeliger self-assigned this Oct 30, 2025
@ohadzeliger ohadzeliger added the bug fix Change that fixes a bug label Oct 30, 2025
@ohadzeliger ohadzeliger marked this pull request as draft October 31, 2025 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug fix Change that fixes a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lucene partition record counts are inaccurate when a document is updated multiple times in the same transaction

1 participant