Fix catalog filter refresh behavior

[cursor]

Slack Bug Summary

A Slack bug report noted that catalog search/filter results can feel inconsistent after changing criteria, and asked whether the issue is in the WebAppComponents catalog UI or Catalog.API query logic.

Source report: Slack channel C0BBF18CAPK, thread 1782240071.077039.

Root Cause

The Catalog.API v2 query logic applies name, type, and brand filters before count/pagination, and local verification did not show a backend filter mismatch. The safer UI issue is that src/WebApp/Components/Pages/Catalog/Catalog.razor loaded catalog results in OnInitializedAsync, even though the page's data is driven by query-string parameters (page, brand, type). That made the WebApp less robust than the sibling HybridApp page for parameter-driven navigation. The same pass also found that ?page=0 or negative page values could be converted to a negative zero-based API page index.

Fix Summary

• Changed the WebApp catalog page to load results in OnParametersSetAsync so query-parameter changes drive a fresh catalog request.
• Clamped the user-facing page query parameter to at least 1 before converting to the API's zero-based pageIndex.
• Added Catalog.API functional coverage for type-only filters and filtered later pages.
• Added a Playwright catalog flow covering pagination reset, brand filter, type filter, and clearing the type filter.

Tests Run

• dotnet restore eShop.Web.slnf -p:NuGetAudit=false
• dotnet build eShop.Web.slnf -p:NuGetAudit=false -p:LibraryRestore=False
• dotnet test --project tests/Catalog.FunctionalTests/Catalog.FunctionalTests.csproj -p:NuGetAudit=false -p:LibraryRestore=False --no-build (33 passed)
• ESHOP_USE_HTTP_ENDPOINTS=1 npx playwright test e2e/BrowseItemTest.spec.ts --project "e2e tests without logged in" (2 passed)
• Manual browser walkthrough recorded: /opt/cursor/artifacts/catalog_filter_walkthrough.mp4

Assumptions / Unresolved Questions

• The Slack report did not include screenshots, logs, exact search terms, or reproduction steps, so this is a cautious first pass around the filter/search-adjacent catalog paths.
• Manual and automated checks indicate this is primarily a WebApp catalog UI robustness issue, not a broader Catalog.API filter pattern. The API search behavior still uses prefix matching for name, which may be a separate product-discovery question if users expect full-text search.

  

---

Note

Low Risk
Small, localized catalog UI lifecycle fix with regression tests; no auth, data, or API behavior changes beyond test coverage.

Overview
Fixes inconsistent catalog results when users change brand, type, or page via the URL by reloading the catalog whenever query parameters change, instead of only on first load.

Catalog.razor now fetches in OnParametersSetAsync (aligned with HybridApp) and clamps the page query to at least 1 before calling the API, avoiding invalid zero/negative page indexes.

Adds Catalog API functional tests for type-only filtering and for brand filters on later pages, plus a Playwright flow that checks pagination reset when applying filters and clearing the type filter.

^{Reviewed by Cursor Bugbot for commit 79b7693. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mattfromcursor]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 79b7693. Configure here.}

[cursor]

Overlapping catalog load requests

Medium Severity

Moving catalog loading into OnParametersSetAsync without clearing catalogResult or canceling earlier calls means each query change starts another GetCatalogItems while the UI still shows the previous page and pagination. If requests finish out of order, the grid can disagree with the current page, brand, and type query string—the inconsistency this change targets.

 

^{Reviewed by Cursor Bugbot for commit 79b7693. Configure here.}