query-too-long

• 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 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, 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. 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, of a precondition on a subject that does not hold, of 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, 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:

{
  "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
    }
  }
}