Multiple filters not applied

[Trenly]

Brief description of your issue

When using both --name and --id I would expect a specific package to be found. Multiple results are returned.

Steps to reproduce

Run winget show --name "Microsoft Teams" --id "Microsoft.Teams"

Expected behavior

Found Microsoft Teams [Microsoft.Teams]
Version: 1.6.00.376
Publisher: Microsoft Corporation
Publisher Url: https://www.microsoft.com/en-us
Publisher Support Url: https://support.microsoft.com/en-us/teams
Author: Microsoft Corporation
Moniker: teams
Description: Make amazing things happen together at home, work, and school.
Homepage: https://www.microsoft.com/en-us/microsoft-teams/group-chat-software
License: Proprietary
License Url: https://www.microsoft.com/en-us/legal/terms-of-use
Privacy Url: https://privacy.microsoft.com/en-us/privacystatement
Copyright: (c) Microsoft Corporation. All rights reserved.
Copyright Url: https://www.microsoft.com/en-us/legal/terms-of-use
Release Notes Url: https://support.microsoft.com/en-us/office/what-s-new-in-microsoft-teams-d7092a6d-c896-424c-b362-a472d5f105de
Tags:
  call
  calling
  chat
  collaborate
  collaboration
  conferencing
  meet
  meetings
  team
  teams
  video
  video-conferencing
  voice
  voip
  webinars
Installer:
  Installer Type: exe
  Installer Url: https://statics.teams.cdn.office.net/production-windows-x64/1.6.00.376/Teams_windows_x64.exe
  Installer SHA256: 09c4f7bb78a1ec44132214b6a7467dd7c3c9f176a9176cf9c370c9a67530d44b

Actual behavior

Multiple packages found matching input criteria. Please refine the input.
Name            Id              Source
---------------------------------------
Microsoft Teams XP8BT8DW290MPQ  msstore
Microsoft Teams Microsoft.Teams winget

Environment

PS C:\git\winget-pkgs> winget --info
Windows Package Manager (Preview) v1.5.441-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.2486
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.441.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

[denelon]

I think this one ends up being chalked up to the implementation on the "msstore" REST source.

winget search --id Microsoft.Teams -s msstore --verbose-logs --open-logs
No package found matching input criteria.

WinGet-2023-02-14-16-27-50.008.log

winget search --name "Microsoft Teams" -s msstore --verbose-logs --open-logs
Name            Id             Version
--------------------------------------
Microsoft Teams XP8BT8DW290MPQ Unknown

WinGet-2023-02-14-16-29-40.703.log

winget search --id "Microsoft.Teams" --name "Microsoft Teams" -s msstore --verbose-logs --open-logs
Name            Id             Version
--------------------------------------
Microsoft Teams XP8BT8DW290MPQ Unknown

WinGet-2023-02-14-16-32-09.952.log

[Trenly]

@denelon - while that may be true, I would expect that the applicability filters perform a "sanity check" after the results have been returned; Even though the msstore source returns the package, the results should be run through the ID applicability filter to ensure the intent is matched.

Essentially, when the results are aggregated, they should probably still be checked against the user intent.

Imagine for a moment it is a private restsource that is improperly implemented and always returns a list of all packages in the source. Users would not blame the source, they would blame the client; even after its been confirmed to be the rest source misbehaving, users would likely expect the CLI to be smart enough to double check the package applicability to their query just like it checks the installer applicability to their machine

[denelon]

I was just talking with the engineering team about this. We don't actually split the request into separate queries. It would mean implementing additional post processing logic in WinGet.

I don't necessarily like having to handle an incorrect implementation of the REST API, but I think for the sake of user experience, it may very well be worth doing.

[Trenly]

Hmm. Interesting. Definitely a complex problem. I’m sure the team will decide on a path that is best