demo(16-tolist-in-loop): 16 — LINQ scan inside a per-request loop

[EricCogen]

16 — LINQ scan inside a per-request loop

Expected verdict: ❌ Fails — GauntletCI should fire GCI0044 (performance hot-path risk).

What changed

A new OrderItemDeduplicator runs a Where scan inside a foreach
over the same list, materialising it with .ToList() on each
iteration:

public sealed class OrderItemDeduplicator
{
    public IReadOnlyList<IReadOnlyList<OrderItem>> GroupBySku(Order order)
    {
        var groups = new List<IReadOnlyList<OrderItem>>();
        foreach (var item in order.Items)
        {
            var matches = order.Items
                .Where(i => i.Sku == item.Sku)
                .ToList();
            groups.Add(matches);
        }
        return groups;
    }
}

For an order with n items this is O(n²). For a single-item order it
is fine. For the larger orders the analytics team has been asking
about it falls over.

Why this is risky

• The hot path here is the order-processing request, which already
  carries DB and payment latency. Spending O(n²) CPU on a list scan
  is exactly the kind of cost that disappears in dev and surfaces
  during a launch promo.
• The fix is mechanical: hoist the grouping out into a single
  GroupBy (or build a Dictionary<Sku, List<OrderItem>>) before
  the loop. One pass, O(n).
• "It's only n²" is the most common production-incident footgun
  in this codebase shape; GauntletCI flags it before the n grows.

What GauntletCI catches

GCI0044 Performance Hotpath Risk — a LINQ method (.Where(,
.Select(, .FirstOrDefault(, .Any(, .Count() on an added line
nested inside a for/foreach/while loop in a non-test, non-rule
file.

[github-actions]

GauntletCI found issues in this PR. See inline comments for details.

[github-actions]

GCI0044 — Performance Hotpath Risk

LINQ query inside a loop

Evidence:

Line 13: .Where(i => i.Sku == item.Sku)

⚠️ Why it matters: LINQ queries inside loops cause repeated enumeration, yielding O(n²) or worse complexity that degrades performance at scale.

💡 Suggested action: Move the LINQ query outside the loop, pre-compute the result into a collection, or use a dictionary/lookup for O(1) access.

_{Confidence: Medium | Severity: Info}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e4c2ebda8b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Precompute SKU groups outside the item loop

This method runs order.Items.Where(...).ToList() inside a foreach over order.Items, which means an order with n items triggers n full list scans and n extra allocations (O(n²)). On larger orders, this creates avoidable CPU and GC pressure in the processing path; build the SKU groups once (e.g., GroupBy/dictionary) and reuse them instead of re-filtering on each iteration.

Useful? React with 👍 / 👎.