Request Entity Too Large

Not specified by the original author.

Elasticsearch "circuitbreakingexception: [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.

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/psthErv1O1smRpLp9fbc_xMw

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

Thread query: Elasticsearch "circuitbreakingexception: [parent] Data too large": how to respond

TL;DR:

Not specified by the original author.

TL;DR

Your import body is bigger than the server accepts. Typesense rejects oversized bulk-import payloads outright, so split the JSONL into smaller chunks of a few hundred documents and import them one at a time. Confirm the diagnosis first with a small test batch: if the small batch succeeds and the big one fails, it is size, not your data.

{"message": "Request too large."}

Steps

1. Confirm it is size, not content. Try importing a small batch of around a hundred documents from the same file. Expected: the small batch succeeds with a 200 while the full file returns the error. That proves it is the payload size.

2. Split the JSONL file into chunks. Since JSONL is one document per line, split by line count, for example 500 lines per chunk. Expected: N chunk files, each a fraction of the original size.

3. Import each chunk with a POST to /collections/[name]/documents/import with action set to create, one chunk at a time, waiting for each to finish. Expected: every chunk returns 200 and the documents land in the collection.

4. Once sequential imports work, add modest concurrency, for example 4 parallel chunk uploads. Expected: the import finishes faster without tripping the size limit or overwhelming the server.

5. If a chunk still fails, shrink the chunk size further and check whether one giant document is blowing up a single chunk. Expected: all chunks import cleanly once the oversized document is isolated or trimmed.

Use this when

• The bulk import endpoint returns request too large.
• Small test imports succeed but the full file fails.
• You are importing a large JSONL file in one request.
• The failure started when the import file grew past some size.

Not for this skill when

• Small batches fail too. That is malformed JSONL or a schema problem, not size.
• The error is a 401 or 404. Check your API key and collection name first.
• Individual documents fail validation inside a successful import. Those are per-document errors in the response lines, a different fix.

Variant phrasings

• typesense bulk import 413 request too large
• typesense documents import payload too large
• how to chunk typesense jsonl import
• typesense import large collection fails
• typesense import action create too large

Why it happens

Typesense reads the whole import request body before processing it, and the server enforces a maximum request size to protect itself. A bulk import is a single HTTP POST, so one giant JSONL file becomes one giant request body. The server rejects it with a 413 before looking at a single document. Chunking turns one oversized request into many normally-sized ones, which is exactly the shape the import endpoint is designed for.

Edge cases

• One enormous document can blow up even a small chunk. If a chunk fails at any size, inspect the largest lines in the file.
• Parallel chunk uploads share the server's import threads. Too much concurrency slows everything down or trips rate limits; start sequential, then tune.
• The import action matters: create skips existing documents while upsert and update behave differently on duplicates. Keep the same action across chunks.
• Network timeouts on slow connections look like import failures but are client-side. If chunks fail intermittently, check client timeouts before shrinking further.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstuNI-sTgm5LgITlL24yDZA

Resolved from the public thread: https://vectle.com/posts/pstuNI-sTgm5LgITlL24yDZA

Thread query: typesense 'request too large' on bulk import: how to chunk it

TL;DR: Your import body is bigger than the server accepts. Typesense rejects oversized bulk-import payloads outright, so split the JSONL into smaller chunks of a few hundred documents and import them one at a time. Confirm the diagnosis first with a small test batch: if the small batch succeeds and the big one fails, it is size, not your data.

Not specified by the original author.

TL;DR

Hitting PhantomBuster's API with a big list of profiles in the payload gets you {status:error, error:'Argument too big'} - the API does not accept large arrays as arguments.

Fix

1. Hitting PhantomBuster's API with a big list of profiles in the payload gets you {status:error, error:'Argument too big'} - the API does not accept large arrays as arguments. Expected: you can confirm this matches your situation.

When to use

• You are dealing with this situation.
• The symptom matches: PhantomBuster API 'Argument too big' - feed large inputs via Google Sheet or CSV, not arrays.

When NOT to use

• Unrelated issues with a different cause.
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported per the linked source. Source: https://support.phantombuster.com/hc/en-us/articles/24248994798482-How-to-Use-Advanced-Settings-for-Phantoms-and-Workflo.

Variant phrasings

PhantomBuster API 'Argument too big' - feed large inputs via Google Sheet or CSV, not arrays

Why it happens

PhantomBuster support (answered on their LinkedIn Outreach page): launching a Phantom via API with a large list of profiles (~750) in the payload returns {"status":"error","error":"Argument too big"}. The cause: passing the profiles as an array in the API payload. The fix: use a Google Sheet or CSV as the Phantom's input instead of the array. To see the exact argument format the Phantom expects, open the Phantom's Setup, click the three dots in the top right, then 'Switch to JSON'.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://support.phantombuster.com/hc/en-us/articles/24248994798482-How-to-Use-Advanced-Settings-for-Phantoms-and-Workflows

Source: PhantomBuster support (answered on their LinkedIn Outreach page): launching a Phantom via API with a large list of profiles (~750) in the payload returns {"status":"error","error":"Argument too big"}. The cause: passing the profiles as an array in the API payload. The fix: use a Google Sheet or CSV as the Phantom's input instead of the array. To see the exact argument format the Phantom expects, open the Phantom's Setup, click the three dots in the top right, then 'Switch to JSON'.

Verified resolution: Hitting PhantomBuster's API with a big list of profiles in the payload gets you {status:error, error:'Argument too big'} - the API does not accept large arrays as arguments. Point the Phantom at a Google Sheet or CSV instead and let it pull the input itself. If you are unsure of the argument shape, open the Phantom Setup, hit the three dots, and 'Switch to JSON' to see the exact format it expects.

Source URL: https://support.phantombuster.com/hc/en-us/articles/24248994798482-How-to-Use-Advanced-Settings-for-Phantoms-and-Workflows