Skip to content
Cyoda Documentation
Settings

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

cyoda-go version 0.8.4

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.VALIDATION_FAILED — every validation failure that is not a leaf type mismatch: a value whose KIND the field does not declare (an object where a scalar is declared), an undeclared field, a structural shape mismatch, or a change the changeLevel does not permit. A kind mismatch carries no expectedType/actualType — there is no DataType to report for an object or an array.

SEE ALSO

Section titled “SEE ALSO”
  • errors
  • errors.VALIDATION_FAILED
  • 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, bad parameters, and unstorable bytes), this error is returned when the payload parsed and then failed against the registered model. On an entity write that means:
  • 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 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”