fix(search): restore cross-field Cmd-K matches - #6193
Conversation
Routing folder paths through filterAndCap's secondary-rank parameter (#6192) fixed folder text outranking exact name matches, but scoreItem matches the name or the secondary text, never the two together -- so a query spanning both, like "leads emea" for a Leads table in EMEA, stopped matching anything. Falls back to matching the joined text when neither field matches alone. That runs last so a secondary hit still cannot masquerade as a name hit, keeping the ranking #6192 established.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryLow Risk Overview In Adds four tests for cross-field match, name-over-secondary ranking, secondary-only match, and no match. Reviewed by Cursor Bugbot for commit f4683a4. Configure here. |
Greptile SummaryThe PR restores Cmd-K queries that span an item's primary name and secondary searchable text while retaining the existing preference for direct name matches.
Confidence Score: 5/5The PR appears safe to merge, with the intended cross-field search behavior restored without weakening direct-name ranking. The joined fallback runs only after both individual fields fail, absent secondary values remain protected by the existing guard, and match positions are discarded by the sole scoring consumer.
|
| Filename | Overview |
|---|---|
| apps/sim/app/workspace/[workspaceId]/w/components/sidebar/components/search-modal/utils.ts | Adds a guarded joined-field fallback after name-only and secondary-only matching; no actionable defect was identified. |
| apps/sim/app/workspace/[workspaceId]/w/components/sidebar/components/search-modal/utils.test.ts | Adds focused regression tests covering the intended cross-field behavior and preserved ranking semantics. |
Reviews (1): Last reviewed commit: "fix(search): restore cross-field Cmd-K m..." | Re-trigger Greptile
Summary
Follow-up to #6192, fixing a regression Cursor Bugbot caught there after it merged.
#6192 moved folder paths out of the primary fuzzy haystack into
filterAndCap'stoExtraparameter, so an exact name match could no longer be outranked by a folder that happened to fuzzy-match. That ranking fix was right, butscoreItemmatches the name or the secondary text and never the two together — so a query spanning both stopped matching at all:"leads emea"for aLeadstable in theEMEAfolder → no resultsFix
scoreItemnow falls back to matching the two fields joined, but only when neither matches alone. Ordering matters: the joined attempt runs last so a secondary-text hit still cannot masquerade as a name hit, preserving the ranking #6192 established.Positions from the joined match don't index into either field — safe here only because
filterAndSortscores with them and discards them. Called that out in the TSDoc so nobody later feeds them to a highlighter.Type of Change
Testing
tscandbun run lint:checkpassChecklist