[ZEPPELIN-6345] Fire NoteRemove event for each note when deleting a folder#5292
Merged
Merged
Conversation
…older Deleting a folder (emptying trash or removing a folder permanently) left the notes searchable because their remove listeners never fired, so the Lucene search index kept stale documents for the deleted notes. removeFolder(String, AuthenticationInfo) called noteManager.removeFolder first, which detached the notes from the tree, so the following removeNote(noteId) loaded a null note and skipped fireNoteRemoveEvent. deleteNoteIndex was never invoked and the notes stayed in the search index after deletion. Load the notes non-destructively via NoteManager.getNoteInfoRecursively, fire the per-note remove cleanup (setRemoved, removeNoteAuth, fireNoteRemoveEvent) mirroring removeNote(Note, AuthenticationInfo), then delete the folder. This also removes the pre-existing "NotebookRepo.remove is called twice" TODO.
Contributor
|
LGTM :) |
ParkGyeongTae
approved these changes
Jul 13, 2026
ParkGyeongTae
left a comment
ParkGyeongTae
left a comment
Member
There was a problem hiding this comment.
LGTM. The root cause analysis is accurate — moving noteManager.removeFolder()
to after the per-note cleanup ensures processNote() can still find each note
in notesInfo and fire NoteRemoveEvent correctly.
While reviewing this, I noticed that removeFolder does not evict note cache
entries via noteCache.removeNote(), which is a pre-existing issue unrelated
to this fix. I've filed a separate Jira ticket for it — feel free to take a
look if you're interested.
https://issues.apache.org/jira/projects/ZEPPELIN/issues/ZEPPELIN-6529
Contributor
Author
|
@ParkGyeongTae Thanks for filing ZEPPELIN-6529 and letting me know! Confirmed the bug and sent a PR here: #5296 |
Member
|
Thanks for the quick follow-up! I'll take a look at #5296. |
Member
|
Merged into master (0c4b30f). |
jongyoul
pushed a commit
that referenced
this pull request
Jul 14, 2026
### What is this PR for? `NoteManager.removeFolder` removed the deleted notes from `notesInfo` and the in-memory folder tree, but never evicted them from the `NoteCache`. `removeNote(String, AuthenticationInfo)` already calls `noteCache.removeNote(noteId)`, so the single-note path is clean; the folder path was not. As a result the `Note` objects for deleted notes stayed on the heap until the LRU threshold naturally evicted them, and they kept occupying cache slots that live notes could otherwise use. This is most wasteful for large folder deletions such as emptying the trash. This PR evicts each removed note from `noteCache` in the same loop that clears `notesInfo`, mirroring the single-note removal path. There is no functional/correctness change (`processNote` already gates on `notesInfo.containsKey`), only immediate reclamation of the cache slots and heap held by deleted notes. This was found by <at>ParkGyeongTae while reviewing #5288 / #5292 (ZEPPELIN-6345). ### What type of PR is it? Improvement ### What is the Jira issue? * https://issues.apache.org/jira/browse/ZEPPELIN-6529 ### How should this be tested? * Added `NoteManagerTest#testRemoveFolderEvictsNoteCache`: adds two notes under `/folder1`, asserts `getCacheSize() == 2`, calls `removeFolder("/folder1", ...)`, and asserts `getCacheSize() == 0`. Fails before the change (cache size stays `2`), passes after. * Full `NoteManagerTest` passes (6 tests), including `testLruCache` and `testNoteOperations`. ### Questions: * Does the license files need to update? No * Is there breaking changes for older versions? No * Does this needs documentation? No Closes #5296 from HwangRock/ZEPPELIN-6529-pr. Signed-off-by: Jongyoul Lee <jongyoul@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR for?
Deleting a folder left its notes searchable after removal.
removeFolder(String, AuthenticationInfo)inNotebookcallednoteManager.removeFolderfirst, which detached the notes from the tree, so the followingremoveNote(noteId)loaded anullnote and skippedfireNoteRemoveEvent.SearchService.deleteNoteIndexwas therefore never invoked and the Lucene search index kept stale documents for the deleted notes, so they still showed up in search results after emptying the trash or removing a folder.This PR loads the notes non-destructively via a new
NoteManager.getNoteInfoRecursively, runs the same per-note cleanup asremoveNote(Note, AuthenticationInfo)(setRemoved,removeNoteAuth,fireNoteRemoveEvent) for each note, and only then deletes the folder. This also removes the pre-existingNotebookRepo.remove is called twiceTODO, since the repo remove now happens once.What type of PR is it?
Bug Fix
What is the Jira issue?
Screenshots (if appropriate)
2026-07-12.5.44.20.mov
How should this be tested?
NotebookTest#testRemoveFolderFiresNoteRemoveEventForEachNote: creates two notes under/folder1, registers aNoteEventListenercountingonNoteRemove, callsremoveFolder("/folder1", ...), and asserts the event fired once per note. Fails before the change (count0), passes after.Questions: