{
  "id": 8220424,
  "title": "The LINQ Query That Never Runs (Until You Force It)",
  "url": "https://urgent.news/2026/09/18/the-linq-query-that-never-runs-until-you-force-it",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-18T09:19:22.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/homolibere/the-linq-query-that-never-runs-until-you-force-it-2joe"
  },
  "original_language": "en",
  "account": "A LINQ query may appear to execute immediately when written, but in reality, it does not. The query only creates a recipe for how to process the data, not the data itself. The actual filtering, sorting, or other operations are deferred until the query is iterated over using constructs like `foreach`, `ToList()`, `Count()`, or `First()`.\n\nFor example, consider a query that filters products priced above $100:\n\n```csharp\nvar filtered = products.Where(p => p.Price > 100);\n```\n\nIn this case, `filtered` holds the recipe, not the actual filtered products. The filtering only occurs when the query is iterated:\n\n```csharp\nforeach (var product in filtered) {\n// Process each product\n}\n```\n\nThis deferred execution behavior can lead to confusion and performance issues. LINQ remembers the source data, not a snapshot, so any modifications to the source after the query is created will affect the results of the query. For instance, if you add a new element to a list that is used as the source for a LINQ query, the query will reflect this change.\n\nThis multiple execution trap can result in multiple database hits or other side effects, as each iteration of the query will re-evaluate against the current state of the source data. To avoid this, materialize the query results when you need stable data:\n\n```csharp\nvar products = products.Where(p => p.Category == \"Electronics\").ToList();\n```\n\nThis forces the query to execute immediately, storing the results in a list that can be iterated over multiple times without additional database hits.\n\nThe concept of deferred execution comes from functional programming's lazy evaluation, which dates back to 1976. LINQ brought this concept into mainstream C# development in 2007, but many developers have struggled to understand and use it effectively. In some cases, deferred execution can be beneficial, such as when composing queries conditionally before execution, allowing the database to optimize the query into a single, efficient form.\n\nHowever, when you need to pass query results around or perform multiple enumerations, it's best to materialize the results using methods like `ToList()`, `ToArray()`, or `ToDictionary()`. This ensures that the query is executed once and the results are stored in memory for subsequent use.",
  "summary": "The LINQ Query That Never Runs (Until You Force It) You write a LINQ query. It compiles. It looks correct. But something is off — it executes at the weirdest times, or worse, executes multiple times when you expected once. Welcome to deferred execution — LINQ's most misunderstood feature. The Illusion of Immediate Most developers assume this runs immediately: var filtered = products . Where ( p…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}