Skip to content
Cyoda Documentation
Settings

INVALID_CONDITION — request condition is malformed or unevaluable

cyoda-go version 0.8.4

errors.INVALID_CONDITION

Section titled “errors.INVALID_CONDITION”

NAME

Section titled “NAME”

INVALID_CONDITION — a request body condition (AbstractConditionDto) was malformed, or is well-formed but carries a leaf no backend can evaluate.

SYNOPSIS

Section titled “SYNOPSIS”

HTTP: 400 Bad Request. Retryable: no.

DESCRIPTION

Section titled “DESCRIPTION”

Endpoints that accept a search-style condition in the request body — sync and async search, grouped statistics, and the conditional form of delete-by-model — reject a body whose condition cannot be parsed or is otherwise structurally invalid. The condition type is unrecognised, a nested clause is malformed, the JSON does not match the expected condition envelope, an operatorType is not one of the canonical operators, a LIKE or MATCHES_PATTERN operand is not a valid pattern, a BETWEEN/BETWEEN_INCLUSIVE operator’s value is not a two-element array, a group clause’s operator is not AND, OR, or NOT, or a NOT group’s conditions does not hold exactly one entry (zero, or two or more).

A function clause at any depth is also rejected here: it is a workflow/transition-criterion shape the engine dispatches to a compute member, and search has no dispatcher for it. Move the predicate into a workflow or transition criterion, or express the search with simple/lifecycle/group/array clauses.

A well-formed condition also lands here when a leaf cannot be evaluated at all. The commonest cause is a comparison against a field the model declares no type for: the type check treats an undeclared field as carrying no constraint and accepts it, and the evaluator then has nothing to compare against. The response reads condition contains a leaf the backend cannot evaluate. This is not a parse failure — the body is syntactically correct, so re-checking the JSON will not help. Check that the jsonPath names a field the model actually declares, and that the model has observed data for it. A leaf whose operand parses into none of a field’s declared types is the distinct CONDITION_TYPE_MISMATCH instead.

To resolve: correct the condition body to a valid AbstractConditionDto (see cyoda help search), or correct the jsonPath to a declared field.

SEE ALSO

Section titled “SEE ALSO”
  • errors
  • errors.CONDITION_TYPE_MISMATCH
  • errors.BAD_REQUEST

See also

Section titled “See also”
  • cyoda help errors — Every error response from the Cyoda REST API carries a structured errorCode in the properties object. Multiple codes may share the same HTTP status. Programmatic handling keys on errorCode, not HTTP status.
  • cyoda help errors BAD_REQUEST — Fired when the server cannot parse or structurally process the incoming request. Common triggers include invalid JSON, unsupported format specifiers, a parameter outside its allowed range, and mutually exclusive parameters set together.
  • cyoda help errors CONDITION_TYPE_MISMATCH — Validation is parse-based: a comparison or range operand is rejected only when it parses into none of the field’s declared DataTypes. For example "abc" against a DOUBLE field is rejected — it is not a number. A numeric-looking string against a polymorphic [INTEGER, STRING] field is accepted (it parses as STRING).

Raw formats

Section titled “Raw formats”