Skip to content
Cyoda Documentation
Settings

INCOMPATIBLE_TYPE — entity payload value does not match the model's declared DataType

cyoda-go version 0.7.1

errors.INCOMPATIBLE_TYPE

Section titled “errors.INCOMPATIBLE_TYPE”

NAME

Section titled “NAME”

INCOMPATIBLE_TYPE — an entity create or update payload carried a leaf value whose inferred DataType is not assignable to the schema’s declared DataType for that path.

SYNOPSIS

Section titled “SYNOPSIS”

HTTP: 400 Bad Request. Retryable: no.

DESCRIPTION

Section titled “DESCRIPTION”

Returned by POST /entity/{format}/{name}/{version} and the entity-update surfaces when a leaf field’s value cannot be coerced into the model’s declared DataType (e.g. submitting "abc" against an INTEGER field, or 13.111 against an INTEGER field on a model whose changeLevel is empty so type widening is not in scope).

Equivalent to Cloud’s FoundIncompatibleTypeWithEntityModelException.

The problem-detail body carries the structured fields below in properties, so SDKs can branch on the precondition without scraping the message string:

  • entityName — model name (e.g. "nobel-prize")
  • entityVersion — model version as a string (e.g. "1")
  • fieldPath — dotted path of the offending leaf (e.g. "price", "address.zip")
  • expectedType — array of declared DataType names for that path (e.g. ["INTEGER"]); usually one entry, more than one when the schema’s TypeSet has been widened by a prior extension
  • actualType — the DataType inferred from the supplied value (e.g. "DOUBLE", "STRING")

Not retryable. The caller must either correct the payload (cast/format the value into the declared type) or, if the model’s changeLevel permits, request a schema extension that widens the field’s TypeSet.

This code is distinct from:

  • errors.CONDITION_TYPE_MISMATCH — search-side equivalent, raised when a search condition’s literal value does not match the field’s locked DataType.
  • errors.POLYMORPHIC_SLOT — payload selects a structural variant the schema does not declare (object vs leaf, or one variant of a polymorphic union).
  • errors.VALIDATION_FAILED — generic validation failure that is not a leaf type mismatch (e.g. a missing required field, a structural shape mismatch).

SEE ALSO

Section titled “SEE ALSO”
  • errors
  • errors.VALIDATION_FAILED
  • errors.POLYMORPHIC_SLOT
  • errors.BAD_REQUEST
  • crud

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 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.
  • cyoda help errors POLYMORPHIC_SLOT — A model can define polymorphic slots — fields whose schema varies based on a discriminator value. This error fires when the payload’s discriminator selects a variant whose schema the provided data fails to match, or when the discriminator value itself is unrecognised.
  • 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 crud — Entities are instances of models. Each entity has a UUID, a model reference (entityName, modelVersion), and a lifecycle state managed by the workflow engine. Creating an entity requires the referenced model to be in LOCKED state. All write operations run within a Cyoda transaction and return a transactionId alongside the affected entity IDs.

Raw formats

Section titled “Raw formats”