Skip to content
Cyoda Documentation
Settings

INVALID_FIELD_PATH — search condition references unknown field path

cyoda-go version 0.8.3

errors.INVALID_FIELD_PATH

Section titled “errors.INVALID_FIELD_PATH”

NAME

Section titled “NAME”

INVALID_FIELD_PATH — a search condition references one or more JSONPath field paths that are absent from the target model’s locked schema.

SYNOPSIS

Section titled “SYNOPSIS”

HTTP: 400 Bad Request. Retryable: no (unless the model schema is then extended via re-import; the request is then valid against the new locked schema).

DESCRIPTION

Section titled “DESCRIPTION”

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.

A path that is a pure container — a known structural interior with substructure (an object with child fields) but no scalar observation of its own — is also rejected this way when compared with a scalar operator: a container has no scalar value to compare against, so the client must navigate to a leaf sub-path. IS_NULL/NOT_NULL are exempt (they test presence, not a value) and remain valid on a container path. A path observed as both an object and a bare scalar across different entities is not a pure container — it is searchable via its scalar type, and the object-valued entities remain reachable through their child leaves.

If any referenced path is unknown, the server performs at most one bounded RefreshAndGet against the model store to recover from a stale cached schema. If the path is still unknown after the refresh, the request is rejected with HTTP 400 and errorCode: "INVALID_FIELD_PATH". The response detail names every offending path so clients can correct the request without round-tripping to the support team.

A condition referencing an unrecognized lifecycle/meta filter field (not one of the known state, creationDate, lastUpdateTime, transitionForLatestSave/previousTransition, transactionId, id fields) is rejected the same way, on both /search and the grouped-statistics endpoint (POST /api/entity/stats/{entityName}/{modelVersion}/query). Grouped statistics does not have data-model schema access, so it enforces this meta-field check but not the schema-backed data-field-path check described above.

Programmatic clients should branch on errorCode == "INVALID_FIELD_PATH" (not on HTTP 400) to distinguish unknown-field-path errors from other 400s such as BAD_REQUEST (malformed JSON) or CONDITION_TYPE_MISMATCH (incompatible value type).

Common causes:

  • The condition references a field that has not been declared in the model schema.
  • The model has been re-imported with a different shape and the client’s condition uses an old field name.
  • The path is misspelled (e.g. $.Name vs $.name).

To resolve: verify the field path against the model’s schema (GET /api/model/.../export), or extend the model schema and re-lock it before retrying.

SEE ALSO

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

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 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).
  • cyoda help search — Search operates against a specific entity model (entityName, modelVersion). Two modes are supported:

Raw formats

Section titled “Raw formats”