Repository navigation
Fix unified search lexical tiebreaks for values and connectors - #141
Conversation
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
📝 WalkthroughWalkthroughRefactored phrase-level bonus scoring logic for value and connector entities by extracting inline calculations into dedicated functions ( Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
|
🔎 Preview deployed: https://kody-pr-141.kentcdodds.workers.dev Worker: Mocks:
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/worker/src/mcp/capabilities/unified-search.workers.test.ts (1)
390-407: Strengthen tie-break tests by asserting the competing capability is present.These assertions prove rank-1 output, but they don’t verify the cross-entity tie path was actually contested. Add a guard that the capability candidate also exists in
result.matchesin both tests.Proposed test hardening
expect(result.matches[0]).toMatchObject({ type: 'value', name: 'preferred_org', }) + expect( + result.matches.some( + (match) => + match.type === 'capability' && match.name === 'preferred_org_lookup', + ), + ).toBe(true) @@ expect(result.matches[0]).toMatchObject({ type: 'connector', connectorName: 'github', }) + expect( + result.matches.some( + (match) => + match.type === 'capability' && match.name === 'github_connector_lookup', + ), + ).toBe(true)Also applies to: 442-459
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/worker/src/mcp/capabilities/unified-search.workers.test.ts` around lines 390 - 407, The test currently only asserts the top-ranked match from searchUnified is the value 'preferred_org' but doesn't verify the competing capability was present to contest the tie; update the test that calls searchUnified (function searchUnified) to also assert that result.matches contains the competing capability candidate (e.g., the other capability's identifier/name/type that should have been in the candidate set) before checking rank-1, and apply the same additional assertion in the sibling test (the similar block around the other test that currently spans lines ~442-459). Ensure you reference result.matches and the competing capability's unique identifier used in the spec so the tie-break path is validated.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/worker/src/mcp/capabilities/unified-search.workers.test.ts`:
- Around line 390-407: The test currently only asserts the top-ranked match from
searchUnified is the value 'preferred_org' but doesn't verify the competing
capability was present to contest the tie; update the test that calls
searchUnified (function searchUnified) to also assert that result.matches
contains the competing capability candidate (e.g., the other capability's
identifier/name/type that should have been in the candidate set) before checking
rank-1, and apply the same additional assertion in the sibling test (the similar
block around the other test that currently spans lines ~442-459). Ensure you
reference result.matches and the competing capability's unique identifier used
in the spec so the tie-break path is validated.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 869fdfaf-e72f-4725-bd35-889a7a19066a
📒 Files selected for processing (2)
packages/worker/src/mcp/capabilities/unified-search.tspackages/worker/src/mcp/capabilities/unified-search.workers.test.ts
Summary
Testing
Summary by CodeRabbit
Refactor
Tests