fix(hub): source merged-mode search from the server - #657
Open
RonenMars wants to merge 1 commit into
Open
Conversation
Searching the hub in merged mode only filtered conversations that had already been paged in, so anything past the current page was unfindable no matter how specific the query. This is the default experience — stores/settings.ts:133 sets mergeChats to true. mergedClassicItems built its conversation rows from the paged set and never consulted convSearchData, while the non-merged branch at app/index.tsx:510 was already wired to it. That asymmetry was the bug: one branch reached the server, the other did not. Take conversations from useConversationSearch while a query is active, since GET /api/search matches message bodies and so finds conversations the client has never loaded. Verified on an iPhone 17 Pro Max simulator, Release build, against the mock suite: e2e/06_search_anchor.yaml previously failed at conversation-row-conv-search-anchor, and that assertion and the tap that follows it now both pass. tsc holds at the 14-error TS2345 baseline tracked in #606; eslint clean. This fixes the source of the list but not the filtering of it. MergedClassicList still re-filters the server's results on title and preview only, so a conversation matched deep in its message history can be fetched and then dropped on the client. The shared e2e fixture cannot detect that, because its preview contains the query. Refs #646.
This was referenced Aug 12, 2026
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
1 participant
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.
Searching the hub in merged mode only filtered conversations that had already been paged in, so anything past the current page was unfindable no matter how specific the query.
This is the default experience —
stores/settings.ts:133setsmergeChatstotrue.The asymmetry
mergedClassicItemsbuilt its conversation rows from the paged set and never consultedconvSearchData, while the non-merged branch atapp/index.tsx:510was already wired to it.One branch reached the server, the other did not.
useConversationSearchhitsGET /api/search?q=…&limit=50, which matches message bodies — exactly the reach a client-side filter over loaded pages does not have.Verified
On an iPhone 17 Pro Max simulator, Release build, against the mock suite.
e2e/06_search_anchor.yamlpreviously failed atconversation-row-conv-search-anchor.With this change that assertion and the tap that follows it both pass — the anchor conversation is found, is tappable, and opens.
npx tsc --noEmit --pretty falseholds at the 14-errorTS2345baseline tracked in #606.ESLint clean on the changed file.
06_search_anchorstill fails one step later onsearch-match-nav, the in-conversation match navigator.That is a different surface and is not addressed here.
This is half the fix, deliberately
MergedClassicListstill re-filters the server's results infilteredItems, matchingtitleandpreviewonly.A conversation the server matched deep in its message history, whose title and preview contain none of the query terms, is fetched and then silently discarded on the client.
That is the exact case server-side search exists to serve, so the feature still fails where it is most valuable.
The e2e suite cannot detect it.
e2e/fixtures/search-results.jsongives the anchor a preview of "Where did we set the wombat timeout for the retry loop?", which contains the query, so the flow goes green either way.Closing that half needs a unit test where the query appears in neither
titlenorpreview.The remaining work is written up in
docs/prompts/, and #646 stays open for it.Refs #646.