Error condition

`query-too-complex`

A safety limit was exceeded.

Type URI: https://openpredicate.tech/problems/query-too-complex
HTTP status: 400 Bad Request
Defined in: Specification §8

What it means

The filter is valid and every operator in it is served, but it exceeds a limit the server publishes — nesting depth, clause count, the size of an operand set, or pattern length. Limits exist so that an endpoint accepting arbitrary predicates cannot be turned into a denial of service.

What a client does about it

Read the published limits, then split the work: fewer clauses per request, shallower nesting, or smaller $in sets across several requests.

What a server should send

State the limit that was hit and its value. "Too complex" without a number leaves the client guessing how much to cut.

application/problem+json

{
  "type": "https://openpredicate.tech/problems/query-too-complex",
  "title": "Query too complex",
  "status": 400,
  "detail": "Filter nesting depth 12 exceeds the limit of 8.",
  "pointer": "/filter/$and/0/$or/3/$and/1",
  "limits": {
    "maxDepth": 8,
    "maxClauses": 64
  }
}

The wire format is the API's own. The specification mandates the condition, not this envelope: an API with an established error format should express the condition in it rather than carry a second format for one endpoint. The member names above are the recommended ones.

The other conditions

malformed-query — The body does not conform to the grammar.
unknown-field — The path is well-formed but this endpoint does not expose it.
unsupported-operator — The operator is part of the language but not of this endpoint's profiles.
invalid-operand — The operator is supported but the operand is not usable.