-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Warn when an encrypted search runs before the index has finished building #34001
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
t3chguy
merged 4 commits into
element-hq:develop
from
hayaksi1:pr/search-incomplete-warning
Jul 17, 2026
+489
−7
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
80b01c6
Warn when an encrypted search runs before the index has finished buil…
hayaksi1 8b0dfed
Merge branch 'develop' into pr/search-incomplete-warning
t3chguy dc321c5
Scope the partial-index warning to the room being searched
hayaksi1 21d39c1
Also warn when the searched room has not been indexed at all
hayaksi1 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least based on the jsdoc of this method it doesn't sound like it will be all uncrawled rooms, just rooms which are currently being crawled, no? Maybe combining the check with
isRoomIndexedwould be better. I.eroom is not in crawlingRooms && isRoomIndexed(room)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though then also worth updating the callback name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the first half, though,
crawlingRooms()is broader than its jsdoc suggests, and I think the doc is what misled you. It adds every queued checkpoint, not just the one in flight:crawlerCheckpointsis the pending queue, so a room sitting fifth in line is already in the set — it does cover "yet to be indexed", just not under that name. The inline doc on the return type says "The rooms that we are currently crawling", which reads as current-only. I've reworded it to "the rooms with an outstanding crawler checkpoint: the one being crawled right now, and those still queued behind it" — one line inEventIndex.ts, since it caused the misread and would cause the next one. Happy to drop it if you'd rather keep this PR to two files.Your suggestion still closes a real gap, so I've taken it. What the crawl set genuinely can't see is a room with no checkpoint at all — before
addInitialCheckpoints()seeds them, such a room is absent from the set and looks identical to "done". That's the issue's own repro ("log into a new desktop session"), which the previous version would have sat silent through. So room-scoped is nowhas(roomId) || !isRoomIndexed(roomId), i.e. yournot in crawlingRooms && isRoomIndexed(room)inverted.One wrinkle I hit implementing it, which changed the shape slightly.
isRoomIndexedhas no change notification:changedCheckpointis the only eventEventIndexemits, and it fires solely on checkpoint transitions insidecrawlerFunc— adding events to the index emits nothing, and an idle crawler is silent (crawlerCheckpoints.shift()→undefined→idle = true; continue, no emit). So a warning raised purely from!isRoomIndexedonce the crawler has drained would never be re-evaluated and would stick for the session.So I only ask the
isRoomIndexedquestion while the crawler still has work outstanding:That keeps the case you're pointing at (during the initial crawl, my room isn't seeded yet → warn) and drops the stuck one (crawler idle → nothing more is coming, and claiming the index is "still being built" would be untrue). It also self-clears: the crawler emits when it nulls
currentCheckpointon drain, so we get a final event to re-evaluate on. There's a test pinning it — removing the!anyOutstandingguard turns it red.Three smaller notes:
isRoomIndexedis presence-only, so it can't be a drop-in&&. Its contract is "the index contains events for the given room" — ≥1 event, not complete — so it's a floor ("definitely not started"), not a completeness check. I've documented it as that rather than implying more.boolean | undefined(indexManager?.isRoomIndexed(...));undefinedmeans there's no manager to ask, which isn't evidence either way. So it warns on=== false, not!indexed, with a test for it.isRoomIndexedacross every encrypted room would be an IPC round-trip each, perchangedCheckpoint.Renamed as you suggested:
useIsCrawlInProgress→useIsIndexIncomplete. The old name described the old, narrower question. The checkpoint half stays synchronous and seeds the initial state, so the common "actively crawling" case renders without a flash; only the never-indexed refinement awaits, and the state is re-seeded from the checkpoint set on every scope/room change so a previous room's answer can't sit on screen while the lookup is in flight (also tested). A generation counter drops any response the scope has moved on from.