Exercise — Debug a Slow or Irrelevant Search Query

Build the mental model

Across this course, Lesson 6 (`match` vs `term`), Lesson 8 (`text` vs `keyword`), Lesson 10 (`must` vs `filter`), and Lesson 18 (leading wildcards, mapping explosion) all showed patterns that make a query look correct but behave wrong or slow — this exercise is not about reciting those patterns as theory again, but practicing the debugging skill of spotting the symptom yourself in a real broken query snippet. A systematic debugging approach breaks the query into its components (field type, clause type, sort/aggregation logic), first confirms the field's mapping type with `GET /index/_mapping`, runs `explain: true`/`profile: true` (Lessons 13 and 20) to verify actual behavior, and only then targets and fixes the root cause. Distinguish two symptom categories: "no results or wrong results" (a correctness bug, like using `match` on a `keyword` field — an analyzer mismatch) versus "results are right but slow" (a performance bug, like putting a binary criterion inside `must` — unnecessary scoring cost) — they can look similar but have completely different root causes and completely different fixes.

Connect it to a real scenario

Suppose a bug report says the Tutorial Platform's production search feature returns zero results when filtering "advanced tutorials" — first check `GET /tutorials/_mapping` to confirm `difficulty` is a `keyword` field, then discover the buggy query used `match: { difficulty: "Advanced" }` (capitalized) — an analyzed `match` where an analyzer-agnostic exact match should have been used on a `keyword` field, causing a case-sensitivity mismatch; the fix is switching to `term: { difficulty: "advanced" }` (lowercase, a `term` query). For another bug report — profiling the search API's p99 latency reveals a binary filter, `term: { status: "published" }`, sitting inside `must`; the fix is moving it to `filter`, letting Elasticsearch's built-in caching be reused effectively.

• Distinguish "no/wrong results" bugs from "correct but slow results" bugs
• First confirm field type with GET /index/_mapping
• Verify actual behavior with explain: true/profile: true before targeting the root cause

Try the working example

// Buggy query — filtering "advanced" difficulty tutorials returns zero results.
// difficulty is mapped as "keyword".
{
  "query": {
    "bool": {
      "must": [
        { "match": { "difficulty": "Advanced" } },
        { "term": { "status": "published" } }
      ]
    }
  }
}

// Your task: find both problems in this query and rewrite it correctly.

You can write the corrected query, fixing the difficulty filter to a correctly cased `term` query and moving the `status` filter into the `filter` clause.

Elasticsearch Guide — Query DSL — Elastic