# query-too-long

The query of an **[`isEventQlQueryTrue` precondition](/docs/eventsourcingdb/preconditions#iseventqlquerytrue)** is **longer than 100 KiB**.

- **Routes:** `write-events`
- **Description:** `/preconditions/<index>: query is too long: it may have at most 100 KiB`, with the place of the precondition in its list, counting from 0.
- **Details:** **`precondition`**, the place of the precondition in its list, counting from 0.

## Why It Happens

Parsing and evaluating an **[EventQL query](/docs/eventsourcingdb/eventql)** takes memory that grows with its length, and an `isEventQlQueryTrue` precondition is evaluated while **every other write waits**. A query that is run on its own arrives in the body of **[`run-eventql-query`](/docs/eventsourcingdb/api/run-eventql-query)**, which takes at most 100 KiB, while the query of a precondition arrives in the body of a write, which takes up to 10 MiB. EventSourcingDB therefore bounds the query of a precondition to **100 KiB** as well, counted in bytes, so that a precondition may be as long as a query that can be run on its own, see **[Limits](/docs/eventsourcingdb/limits#operational-limits)**. A typical cause is a query that a program **builds**, for example with a comparison or a source for each of thousands of values.

The length is checked **before the query is parsed**, before the events of the write are validated, and before the write waits for the other writes. So a query that is too long is reported this way even where it does not parse, and ahead of a **[violated event schema](/docs/eventsourcingdb/errors/event-schema-violated)**, of a precondition on a subject that does not hold, of **[read-only mode](/docs/eventsourcingdb/read-only-mode)**, and of a full disk. Mistakes of the request itself are still reported first, such as a write without events, reported as **[`events-missing`](/docs/eventsourcingdb/errors/events-missing)**, a mistake in the fields of an event, or a precondition of another one that has no query. If the queries of several preconditions are too long, the error names the first of them in the order of the request.

## How to Fix It

**Shorten the query**: compare a field with **many values at once** through an array and `CONTAINS`, as in `WHERE ["/books/23", "/books/42"] CONTAINS e.subject`, rather than writing a comparison for each value, and leave out comments and whitespace that a program adds. A query of more than 100 KiB cannot be run on its own either, so where a rule needs more, **split it into several preconditions**, each with a query of its own: a write holds only if all of them hold. Sending the same write again fails the same way, since the error depends on the query alone.

## Example

To write an event whose second precondition is an `isEventQlQueryTrue` precondition with a query of more than 100 KiB, EventSourcingDB answers with this error, as a line of the stream, and then ends the stream with its `end` item:

```json
{
  "type": "error",
  "data": {
    "code": "https://docs.eventsourcingdb.io/errors/query-too-long",
    "description": "/preconditions/1: query is too long: it may have at most 100 KiB",
    "details": {
      "precondition": 1
    }
  }
}
```