# INVALID_FIELD_PATH — search condition references unknown field path

Before executing a search, the server validates that every data-field path referenced by the condition (e.g. `$.price`, `$.profile.email`) resolves agains…

<em>cyoda-go version <a href="https://github.com/Cyoda-platform/cyoda-go/releases/tag/v0.7.1">0.7.1</a></em>

# errors.INVALID_FIELD_PATH

## 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

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

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.

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 (issue #77). 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.

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

- errors
- errors.BAD_REQUEST
- errors.CONDITION_TYPE_MISMATCH
- search

## See also

- [`cyoda help errors`](/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`](/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`](/help/errors/condition_type_mismatch/) — Each field in a locked model has an inferred DataType (e.g. INTEGER, DOUBLE, BOOLEAN). When a search condition references a numeric or boolean field, the condition's value must be type-compatible with that field. For example, submitting a string value `"abc"` against a DOUBLE field is rejected.
- [`cyoda help search`](/help/search/) — Search operates against a specific entity model `(entityName, modelVersion)`. Two modes are supported:

## Raw formats

- [`/help/errors/invalid_field_path.json`](/help/errors/invalid_field_path.json) — full descriptor (matches `GET /help/{topic}` envelope)
- [`/help/errors/invalid_field_path.md`](/help/errors/invalid_field_path.md) — body only