# Elasticsearch "circuit_breaking_exception: [parent] Data too large": how to respond

TL;DR: One request asked Elasticsearch to hold more heap than the safety limit allows, so the parent circuit breaker killed it before it could OOM the node. Shrink the request first: smaller aggregation sizes, `search_after` instead of deep pagination, tighter filters. Only raise heap or breaker limits after the query is already lean.

```text
circuit_breaking_exception: [parent] Data too large, data for [indices:data/read/search] would be [3221225472/3gb], which is larger than the limit of [3006477107/2.7gb]
```

## Steps

1. Identify the query. The error names the operation; the slow log shows which dashboard or client sent it.
**Expected:** You know exactly which query trips the breaker.

2. Cut aggregation cost. Lower the `size` on terms aggregations, page through composite aggregations instead of fetching everything, and put filters before the heavy aggs.
**Expected:** Estimated heap per request drops sharply.

3. Replace deep `from`/`size` pagination with `search_after`. Deep pages force the coordinating node to hold and sort huge result sets.
**Expected:** Pagination memory stays flat no matter how deep you go.

4. Kill fielddata usage. Sort and aggregate on keyword fields, not analyzed text; uninverting text into fielddata is one of the most expensive things a query can do.
**Expected:** Fielddata memory is freed and stays freed.

5. If the query is already lean and legitimately large, scale: give the node more heap (no more than half of RAM, and stay under about 31 GB to keep compressed pointers), or add nodes to spread the load.
**Expected:** Breaker trips stop without just moving the crash into the JVM.

## Use this when
- Searches or aggregations fail with a parent `circuit_breaking_exception`

## Not for this skill when
- The fielddata breaker trips on its own. Same family, but the fix is specifically about fielddata
- The container gets OOMKilled. That is infrastructure sizing, not the breaker
- The error is `too_many_clauses`. That is the boolean clause rewrite limit

## Variant phrasings
### Data too large, data for [request] would be larger than the limit
The same parent breaker trip, naming the request circuit instead of the search transport.

## Why it happens
The parent breaker sums all memory accounting on the node and refuses any request that would push heap past the safety margin. It is the last defense before an actual out-of-memory crash, so tripping it means the request was genuinely dangerous, not that the limit is misconfigured.

## Edge cases
- Raising the breaker limit without fixing the query just moves the crash from the breaker to the JVM
- The `request` breaker trips on per-request structures like aggregations; the `fielddata` breaker trips on uninverting; check which one fired
- Breaker trips in the logs are an early warning; graph them and you will see the expensive queries coming

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hErv1O1smRp_Lp9fbc_xMw