Bug: repo_search_commits searchText not passed to API as searchCriteria.messageContains

[iamchenyu]

Description

The repo_search_commits tool's searchText parameter never returns expected results because it is not passed to the Azure DevOps API as searchCriteria.messageContains. Instead, it only performs client-side filtering on the already-limited result set (default top: 10).

Steps to Reproduce

1. Have a repository with a commit message containing "BSC" (e.g., "Merged PR 22210: BSC: Provide the role code dropdown...")
2. Call repo_search_commits with searchText: "BSC", fromDate: "2026-04-01", top: 10
3. Returns []
4. Calling the ADO REST API directly with searchCriteria.messageContains=BSC returns the expected commits

Root Cause

In dist/tools/repositories.js (~line 1481), the searchCriteria object is built without including messageContains:

js
const searchCriteria = {
fromCommitId: fromCommit,
toCommitId: toCommit,
includeLinks: includeLinks,
includeWorkItems: includeWorkItems,
};
// searchText is NOT added here

Then at line 1515, client-side filtering is applied to the already-fetched (and limited) results:

js
if (searchText && filteredCommits) {
filteredCommits = filteredCommits.filter((commit) =>
commit.comment?.toLowerCase().includes(searchText.toLowerCase()));
}

Since the API call respects the top parameter, only the N most recent commits are returned, and the client-side filter searches within those N commits only.

Expected Fix

Add searchText to the API search criteria:

js
if (searchText) {
searchCriteria.messageContains = searchText;
}

Environment

• Package version: 2.7.0
• OS: Windows 11
• Node.js: v20.5.1

[krid-583]

@iamchenyu, the API doesn't seem to support messageContains in its searchCriteria as far as I see.

Please inform me if I am wrong.

[iamchenyu]

@iamchenyu, the API doesn't seem to support messageContains in its searchCriteria as far as I see.

Please inform me if I am wrong.

You're right — I double-checked the official API docs and messageContains is not a supported parameter in GitQueryCommitsCriteria. My earlier test was flawed; the API was simply ignoring the unknown parameter without any errors and returning unfiltered results.

That said, the current client-side filtering approach has a usability issue: it only filters within the top N results (default 10), which makes searchText practically useless for finding historical commits. Users expect it to search across all commits matching their date range.

Would it be feasible to either:

1. Paginate through all results internally before applying the client-side filter, or
2. Document this limitation clearly so users know searchText only searches within the returned page?

[krid-583]

Hey, I looked through this,

The api we are using for this actually has a limit till int max for top value. So it is totally feasible to give a big number for top to ensure that you could cover all the commits you need.

I will update the documentation stating that searchText is not a native filter and searches only within the returned commit list.

[krid-583]

Currently we have decided to remove the support for client-side filters and only use server-side filtering as you can see in the pull request. I hope that is fine. This reduces the confusion overall as we cannot support client-side filters in the long run.

[iamchenyu]

Currently we have decided to remove the support for client-side filters and only use server-side filtering as you can see in the pull request. I hope that is fine. This reduces the confusion overall as we cannot support client-side filters in the long run.

Thanks for the fix!