bhabegger opened a new pull request, #3086:
URL: https://github.com/apache/jackrabbit-oak/pull/3086

   ## Summary
   
   `FulltextIndexEditor.addOrUpdate()` calls `makeDocument()` on every commit 
touching a node. When the node's indexing rule still matches but its last 
indexable content came from a relative/aggregated property that was just 
removed, `makeDocument()` returns `null` (nothing to index) and `addOrUpdate()` 
previously did nothing further — leaving the stale document in the index 
indefinitely.
   
   A direct (non-relative) property removal on the same node was already 
handled correctly: `FulltextDocumentMaker.removeProperties()` forces 
`dirty=true` in that case, so a rebuilt document is written instead of `null`. 
The gap is specifically the aggregated-content case, where the root node's own 
`propertiesModified` list stays empty.
   
   **Fix:** in `addOrUpdate()`, when `makeDocument()` returns `null` on an 
update to a previously-existing node, delete the stale document. Guarded by 
feature toggle `FT_OAK-12365` (enabled by default), following this codebase's 
convention for bug-fix toggles.
   
   Covers both the OAK-12244 type-tracking-enabled path and the legacy 
(toggle-disabled) path, since both funnel through `addOrUpdate()`.
   
   Related but distinct from OAK-12244 (mixin add/remove *rule* transitions): 
this is a *content* transition — the rule still matches throughout, but the 
document's content disappeared.
   
   ## Test plan
   
   - [x] 
`LuceneIndexEditor2Test#nodeLosesLastAggregatedPropertyTriggersDocumentDeletion`
 — unit test verifying `deleteDocument()` is called (new, RED→GREEN)
   - [x] 
`LuceneIndexEditor2Test#nodeLosesLastAggregatedPropertyTriggersDocumentDeletionWhenMixinToggleDisabled`
 — same, with `FT_OAK_12244` disabled to confirm the legacy path is also covered
   - [x] 
`PropertyIndexCommonTest#nodeLosesLastAggregatedPropertyDisappearsFromFulltextIndex`
 — integration test using a fulltext `CONTAINS()` query (a plain equality query 
can't observe this bug, since Oak's query engine revalidates simple `WHERE` 
conditions against the live tree)
   - [x] Full `oak-search` + `oak-lucene` suites: 1250 tests, 0 failures, 0 
errors


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to