Enforce explicit ID filters on REST search results

[AmirMS (AmelBawa-msft)]

📖 Description

Reject REST results that fail explicit package ID filters, preventing a matching name or query from admitting a package with a different ID.

FilterSearchResult reuses comparisons through MatchesRequest for Exact, CaseInsensitive, StartsWith, and Substring matching. Filtering runs before result limits and also applies to optimized ID lookups, preserving pagination and the substring-ID fallback.

Also fix ICUCaseInsensitiveStartsWith to fold complete strings before comparing prefixes, preventing valid Unicode matches from being discarded. Add regression coverage and release notes.

Local rejection is limited to explicit ID filters. Other fields and unsupported match types remain server-evaluated.

🎞️ Demo

🔗 References

Resolves #2966.

🔍 Validation

• Built x64 Debug successfully. Passed 202 native test cases / 2,959 assertions covering strings, REST interfaces, matching, completion, source priority, and composite sources.
• Deployed wingetdev and passed 10 sequential, read-only live CLI checks covering combined filters, case sensitivity, invalid IDs, and Store lookups. Verbose logs confirmed that the original Teams scenario discards Store package XP8BT8DW290MPQ because its ID does not match Microsoft.Teams.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[Copilot]

🟢 Approval recommended

The filtering behavior is correctly integrated across REST paths and supported by focused regression coverage.

Pull request overview

Enforces explicit package ID filters on REST results and fixes Unicode-aware prefix matching.

Changes:

• Filters REST search and optimized lookup results by explicit IDs.
• Corrects Unicode case-folded prefix comparisons.
• Adds regression tests and release notes.

File summaries

File	Description
src/AppInstallerSharedLib/AppInstallerStrings.cpp	Fixes Unicode prefix matching.
src/AppInstallerRepositoryCore/Rest/Schema/1_0/RestInterface_1_0.cpp	Enforces ID filters before limits.
src/AppInstallerRepositoryCore/MatchCriteriaResolver.h	Exposes reusable match evaluation.
src/AppInstallerRepositoryCore/MatchCriteriaResolver.cpp	Implements optional local matching.
src/AppInstallerCLITests/Strings.cpp	Tests Unicode prefix behavior.
src/AppInstallerCLITests/RestInterface_1_1.cpp	Tests inherited REST filtering.
src/AppInstallerCLITests/RestInterface_1_0.cpp	Covers filtering, pagination, and fallback behavior.
src/AppInstallerCLITests/MatchCriteriaResolver.cpp	Tests supported and unsupported match types.
doc/ReleaseNotes.md	Documents both fixes.

Review details

• Files reviewed: 9/9 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[JohnMcPMS]

The scope is too limited and doesn't meet the criteria for the "hero" case. This function generates that:

winget-cli/src/AppInstallerCLICore/Workflows/WorkflowBase.cpp

Lines 879 to 906 in c17eadb

	void GetSearchRequestForSingle(Execution::Context& context)
	{
	const auto& args = context.Args;
	MatchType matchType = MatchType::CaseInsensitive;
	if (args.Contains(Execution::Args::Type::Exact))
	{
	matchType = MatchType::Exact;
	}
	SearchRequest searchRequest;
	// Note: MultiQuery when we need search for single is handled with one sub-context per query.
	if (args.Contains(Execution::Args::Type::Query))
	{
	std::string_view query = args.GetArg(Execution::Args::Type::Query);
	// Regardless of match type, always use an exact match for the system reference strings.
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::PackageFamilyName, MatchType::Exact, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::ProductCode, MatchType::Exact, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::Id, matchType, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::Name, matchType, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::Moniker, matchType, query));
	}
	SearchSourceApplyFilters(context, searchRequest, matchType);
	context.Add<Execution::Data::SearchRequest>(std::move(searchRequest));
	}

We need a more generalized filtering pass, and it should probably live outside of the REST code since it isn't REST specific.

[JohnMcPMS]

Fix the other caller to handle a possible null now. I get that it uses a fixed list and that list won't ever get a null from this implementation, but I don't like having that silent coupling.

[JohnMcPMS]

This ignores Inclusions. The goal should be to ensure that the results reflect the request fully, not just that it works in the narrow case we are targeting.

[ranm-msft]

Read the diff against head (64ae352) and walked FilterSearchResult through SearchInternal's continuation loop. Not re-raising the Inclusions gap or the generalization/placement point - John has those covered.

One thing I'd like your read on, and the new Search_ExplicitIdFilters_Continuation test suggests you already thought about it: the loop's exit condition is results.Matches.size() < request.MaximumResults, and filtering now runs before that count advances. The test encodes exactly that - allFiltered with MaximumResults == 1 still issues all three requests. I think that is the right semantics, since a valid match can live on page three and you cannot stop after N raw candidates. But it does mean MaximumResults no longer bounds round trips at all when a source returns candidates the filter rejects, which is the lax-source case this PR exists for.

Is it worth a separate bound on continuation requests - a page budget, or repeated-token detection - so "limit results" and "limit work" stay distinct concepts? Against a source that pages a broad name match, a bounded request can now walk the whole chain one POST at a time. Happy to be told the practical chain length makes this theoretical.