Skip to content
Cyoda Documentation
Settings

CONDITION_TYPE_MISMATCH — search condition value type incompatible with field

cyoda-go version 0.8.3

errors.CONDITION_TYPE_MISMATCH

Section titled “errors.CONDITION_TYPE_MISMATCH”

NAME

Section titled “NAME”

CONDITION_TYPE_MISMATCH — a search condition’s operand parses into none of the field’s declared DataTypes.

SYNOPSIS

Section titled “SYNOPSIS”

HTTP: 400 Bad Request. Retryable: no.

DESCRIPTION

Section titled “DESCRIPTION”

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).

There is no operator-versus-field-type rejection. CONTAINS on a numeric field, GREATER_THAN "true" on a boolean, and similar are accepted — they parse and simply evaluate to a (non-)match rather than an error. String operators and the IS_NULL/NOT_NULL presence tests carry no operand-type constraint. A field with no declared types, and paths not present in the schema, carry no constraint here; an unknown field path is instead rejected by a separate validation pass with INVALID_FIELD_PATH.

Temporal meta fields (creationDate, lastUpdateTime) follow the same rule: a comparison/range operand must parse into a temporal type. A coarse operand (e.g. a bare year, or an offset-less date-time) upscales and is accepted; only an operand that parses into no temporal type is this error.

Both /search and the grouped-statistics endpoint (POST /api/entity/stats/{entityName}/{modelVersion}/query) enforce this check.

Correct the operand so it denotes a value of one of the target field’s declared DataTypes.

SEE ALSO

Section titled “SEE ALSO”
  • errors
  • errors.BAD_REQUEST
  • errors.INVALID_FIELD_PATH
  • errors.VALIDATION_FAILED

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, missing required fields, unsupported format specifiers, or mutually exclusive parameters being set simultaneously.
  • cyoda help errors INVALID_FIELD_PATH — Before executing a search, the server validates that every data-field path referenced by the condition (e.g. $.price, $.profile.email) resolves against the target model’s locked schema. Lifecycle paths (state, previousTransition, etc.) and meta paths ($._meta.*) bypass this check.
  • cyoda help errors VALIDATION_FAILED — Unlike BAD_REQUEST (which covers parse failures), this error is returned when the payload is parseable but violates the registered model schema — for example, a required field is missing, a value is out of the allowed range, or a workflow guard condition is not satisfied. The error detail includes the specific validation failure.

Raw formats

Section titled “Raw formats”