Closes: #817

Problem

The search_issues tool was incorrectly adding duplicate repo: and is: filters to user queries, causing GitHub API validation errors when users provided queries that already contained these filters. This issue also affected users with complex queries containing multiple OR operators, as the duplicate filters contributed to exceeding GitHub's 5 AND/OR/NOT operator limit.

Example of the bug:

• Input query: "repo:github/github-mcp-server is:issue is:open (label:critical OR label:urgent)"
• Before fix: "is:issue repo:github/github-mcp-server is:issue is:open (label:critical OR label:urgent)" ❌
• After fix: "repo:github/github-mcp-server is:issue is:open (label:critical OR label:urgent)" ✅

Solution

Implemented intelligent filter detection to prevent duplicate filters with a clean, idiomatic approach:

Helper Functions

• hasSpecificFilter(query, filterType, filterValue): Detects exact filter:value combinations (e.g., is:issue)
• hasRepoFilter(query): Simple check for existing repo: filters
• hasFilter(query, filterType): General filter type detection

Updated Logic

• is: filters: Only add is:searchType if the exact combination doesn't already exist
• repo: filters: Only add from owner/repo parameters if query doesn't already have a repo filter
• Simple approach: No complex conflict resolution - just prevent duplicates

The core fix is in searchHandler():

// Only add is:searchType if exact filter doesn't exist
if !hasSpecificFilter(query, "is", searchType) {
    query = fmt.Sprintf("is:%s %s", searchType, query)
}

// Only add repo filter if none exists
if owner != "" && repo != "" && !hasRepoFilter(query) {
    query = fmt.Sprintf("repo:%s/%s %s", owner, repo, query)
}

Team Discussion Context

This implementation follows the approach agreed upon in our team discussion:

• Consensus: Implement smart deduplication as a short-term fix
• Scope: Fix our API's double-encoding behavior, not validate GitHub's search syntax
• Simplicity: Keep logic simple - just prevent duplicate filter addition
• Tool integrity: Maintain semantic separation between search_issues and search_pull_requests
• User experience: Prevent frustrating API validation errors from duplicate filters

Benefits

✅ Prevents API errors: No more "More than five AND/OR/NOT operators were used" errors
✅ Maintains user intent: Existing filters in queries are preserved
✅ Backward compatible: Existing functionality preserved
✅ Clean & maintainable: Simple, focused functions following Go idioms
✅ Applies to both tools: Fixes both search_issues and search_pull_requests (both use searchHandler)

Testing

Added comprehensive test coverage:

• 13 test cases for hasFilter() function
• 10 test cases for hasRepoFilter() function
• 12 test cases for hasSpecificFilter() function
• 4 integration test cases for duplicate filter scenarios
• Updated existing tests to match corrected behavior

All tests pass with 100% coverage of new logic.

Alternatives Considered

1. Complex conflict resolution: Parse and resolve conflicts between query filters and parameters

   • Discarded: Added unnecessary complexity; conflicts are rare and simple prevention is sufficient

2. GitHub API validation: Let the API handle duplicate filters

   • Discarded: API returns validation errors, poor user experience

3. Query parsing library: Use a dedicated GitHub search query parser

   • Discarded: Added significant dependency for a focused problem

4. String replacement: Remove existing filters before adding new ones

   • Discarded: Too fragile, could break legitimate queries with filter-like text

The fix ensures that users can confidently use complex GitHub search queries without encountering unexpected API validation errors, while maintaining the convenience of automatic filter addition for simple queries. The implementation prioritizes simplicity and maintainability over handling edge cases that rarely occur in practice.