[KrzysztofPajak]

What

A product page view did more work than it needed to:

• The view counter was fire-and-forget. ProductController called _ = _productService.IncrementProductField(product, x => x.Viewed, 1) in ProductDetails and in the quick-view action. A failed write was an unobserved task exception that nobody saw. PlaceOrderCommandHandler did the same with the Sold counter.
• Recently viewed did 3–4 round trips. AddProductToRecentlyViewedList deleted the product's row, inserted it again, queried for rows over the limit and then deleted them.
• The recently viewed list was sorted in memory. It is read by CustomerId and ordered by CreatedOnUtc, but the only compound index is CustomerId, ProductId, CreatedOnUtc.

Changes:

• Both Viewed increments are awaited through a CountProductView helper. A failed write is logged as a warning, and the page still renders. It is still one $inc per view; the counter is not buffered.

• The Sold increment in PlaceOrderCommandHandler is awaited the same way: a failed write is logged and the order is still saved. The write runs after the payment is processed, so it must not stop the order.

• AddProductToRecentlyViewedList reads the customer's rows once (Id, ProductId, newest first). It then inserts the viewed product and runs one DeleteManyAsync for:

  • the earlier rows of the same product (two concurrent first views can leave more than one);
  • the oldest rows beyond the limit.

  Insert-then-delete means the viewed product is never missing from the list, even when a concurrent view trims its old row. CreatedOnUtc is always set by the repository's audit clock. The list is trimmed on every view, so a list over the limit (lowered RecentlyViewedProductsNumber, or two concurrent new-product views that deleted the same oldest row) shrinks on the next view.

• New index CustomerId.CreatedOnUtc (CustomerId asc, CreatedOnUtc desc, _id desc) on RecentlyViewedProduct. It is created by the installer and by the 2.5 migration MigrationRecentlyViewedProductCustomerIndex. The existing indexes stay.

IRepository and IRecentlyViewedProductsService are unchanged. ProductController gets an ILogger<ProductController> constructor parameter.

Round trips per product view (recently viewed)

Case	Before	After
Product already in the list	delete + insert + trim query (+ delete) = 3–4	read + insert + delete = 3
New product, list not full	delete + insert + trim query = 3	read + insert = 2
New product, list full	delete + insert + trim query + delete = 4	read + insert + delete = 3

Behavior changes

• The view counter is now awaited, which adds one database round trip to the response time of each product view on MongoDB. On LiteDB it was already synchronous.
• A failed view counter write is now logged instead of being lost; the page is unaffected.
• A failed Sold write is now logged instead of being lost; order placement is unaffected.
• Two concurrent views of new products can leave the list one row over the limit until the customer's next view trims it.

Not changed

• On LiteDB, IncField reads, modifies and writes the document, so concurrent views can still lose increments. Awaiting the call does not change that.

Testing

1. RecentlyViewedProductsServiceTests: 10/10. Tests cover:
   • a re-viewed product keeps a single row;
   • duplicate rows for one product collapse to one row at the top;
   • a lowered limit trims the list, on a new product and on a re-viewed one.
2. ProductControllerPreviewTests: 7/7. They cover the view being counted once, and the page still rendering when the counter write fails.
3. dotnet test src/Tests/Grand.Business.Checkout.Tests: 292/292. The Sold guard has no dedicated test, because reaching SaveOrderDetails needs a full order setup.
4. Grand.Module.Migration builds.

Not done: the races are not covered by unit tests, the migration was not run against a real database, the storefront was not run, and nothing was timed under load.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.