Add fuzzy/typo-tolerant matching for component name and I/O fields

[Mbeaulne]

Description

Adds typo tolerance to the lexical search functionality for component names and input/output fields. When a query token is 4–6 characters, a single-character edit distance is allowed; for tokens 7+ characters, up to two edits are permitted. Fuzzy matches receive a slightly lower score than exact matches via a dedicated FUZZY_MATCH_BONUS_MULTIPLIER. Typo tolerance is intentionally restricted to name and io fields — descriptions and implementation text do not benefit from fuzzy matching to avoid noisy results.

The implementation uses a standard dynamic programming Levenshtein distance algorithm with an early-exit optimisation that abandons the computation once the running row minimum exceeds the allowed distance.

Related Issue and Pull requests

Type of Change

• Bug fix
• New feature
• Improvement
• Cleanup/Refactor
• Breaking change
• Documentation update

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

Test Instructions

1. Run the existing test suite — two new test cases cover the expected behaviour:
   • Confirm that queries like filtr (for filter_rows) and datset (for dataset) return the correct component.
   • Confirm that typo queries against description or implementation text (e.g. xgbost) return no results.

Additional Comments

Fuzzy matching is skipped entirely when the computed max edit distance is 0 (tokens shorter than 4 characters), keeping short-token searches fast and precise.

[github-actions]

🎩 Preview

A preview build has been created at: 06-18-add_safe_typo_tolerance_for_names_and_io_fields/9ae8af8

[Mbeaulne]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add AI model quick-select to app menu and injectable model config #2461
• Simplify component search result cards #2459
• Add context-aware component search suggestions #2458
• Add component discovery docs #2457
• Add component search analytics baseline #2456
• Limit dashboard component browse rendering #2454
• Add component search empty state suggestions #2453
• Decouple editor component search input #2452
• Polish component search explanations #2451
• Add compatible component suggestions #2450
• Add component collection search results #2449
• Add component lifecycle badges #2448
• Add component search URL state #2447
• Disable AI search when literal search finds no matches #2444
• Debounce component search input #2433
• add client-side embeddings cached in IndexedDB #2432
• Add search quality expectation tests for lexical search #2431
• Add deep AI search to rerank all components in selected sources #2430
• Add source-diverse AI rerank candidate pool #2429
• Add negative constraint parsing to lexical search #2428
• Add fuzzy/typo-tolerant matching for component name and I/O fields #2427 👈 (View in Graphite)
• Improve component search scoring relevance #2426
• Add synonym expansion to component lexical search #2425
• Normalize component search tokens for better matching #2424
• Expand component search indexing fields #2423
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camielvs]

🤖 Code review — Add fuzzy/typo-tolerant matching for name and I/O fields

Well-scoped feature. Restricting fuzzy matching to name + io (the high-precision fields), weighting it below exact/prefix (0.75×), and the length-gated edit budget (<5 → none, 5–6 → 1, 7+ → 2) are all the right instincts. The maxTypoDistance comment justifying the length-5 floor with concrete collisions (data↔date, path↔bath, list↔last) is great. The bounded Levenshtein is correct — the length-diff short-circuit and the rowMinimum > maxDistance early-out are both valid. And the negative test asserting xgbost does not fuzzy-match description/implementation text locks the boundary in place.

Findings:

• This is the heaviest per-keystroke addition in the stack. The fuzzy branch runs precisely when !fieldText.includes(token) — i.e. for the majority of (entry, token) pairs, since most entries don't contain most query tokens. For each it runs Levenshtein against every name/io field token. It's bounded (length-diff guard, early-out, length-≥5 gate, two fields only, synonym-expanded token count), so fine for hundreds of components — but stacked on Improve component search scoring relevance #2426's double index pass it's worth watching as libraries grow. lexicalSearch still runs in the render path until Debounce component search input #2433's debounce lands.

• Distance-2 on io tokens is fairly permissive. A 7+ char query token tolerating 2 edits against generic I/O names could surface the occasional surprising match. The name field is high-signal so it's lower-risk there; might be worth a quick sanity check on real I/O vocabularies, or reserving distance-2 for name only. Not blocking.

• Nit: redundant guard in hasFuzzyTokenMatch. !fieldToken.includes(token) can never be false here — the caller only enters the fuzzy branch when the whole fieldText lacks token as a substring, so no individual field token can contain it either. The !token.includes(fieldToken) half is meaningful (skips fuzzy when the field token is a substring of the query token). Dropping the dead half would make the intent clearer.

• Minor (carryover): synonym/stem-expanded tokens also flow through fuzzy matching, so a fuzzy hit on an expanded variant adds another 0.75× contribution — compounding the per-concept stacking noted on Normalize component search tokens for better matching #2424–Improve component search scoring relevance #2426. Low stakes given the 0.75 weight.