Attribute Data Type Changed

This error is reported when an existing attribute keeps the same name but its dataType changes.

Attribute "product.price" changed data type from "string" to "float".

Why This Change Is Not Allowed

Changing dataType in place changes how the generated GraphQL schema and Studio interpret every existing value. Values written using the old type may fail GraphQL coercion, sorting, filtering, form rendering, or writes under the new type.

--allow-breaking-changes cannot override this error. Acknowledgement alone cannot make the stored values compatible.

Use a Staged Migration

Create a new attribute instead of changing the existing attribute:

1. Add a new attribute with a temporary or final name and the desired dataType.
2. Keep the old attribute unchanged.
3. Run flexkit deploy to make both attributes available.
4. Run a migration script that reads the old value, converts and validates it, and writes the new attribute.
5. Verify the migration, including records with missing or invalid source values.
6. Update GraphQL operations, Studio configuration, integrations, and automations to use the new attribute.
7. Remove the old attribute.
8. Run flexkit deploy --allow-breaking-changes to acknowledge that final removal.

For example, migrate price from string to float by temporarily keeping both fields:

attributes: [
  {
    name: 'price',
    label: 'Price (legacy)',
    scope: 'global',
    dataType: 'string',
    inputType: 'text',
  },
  {
    name: 'priceValue',
    label: 'Price',
    scope: 'global',
    dataType: 'float',
    inputType: 'number',
  },
]

Migration Script Requirements

Use your project’s authenticated GraphQL API to migrate records in batches. For every record, the script should:

• Read the old attribute and a stable record identifier.
• Explicitly convert the value to the new type.
• Reject or record values that cannot be converted safely.
• Write the converted value to the new attribute.
• Support retries without corrupting already migrated records.
• Produce counts for scanned, migrated, skipped, and failed records.

Test the conversion against a representative data sample before migrating all records. Back up or export important data and retain a report of rejected values.

Validate Before Removing the Old Attribute

Check that:

• Expected records have a value in the new attribute.
• Converted values preserve the intended meaning and precision.
• Studio can read, edit, filter, and sort the new field.
• GraphQL operations and other consumers no longer request the old field.
• The migration script has no unresolved failures.

Only then remove the old attribute and acknowledge its removal. The old stored values will remain orphaned until Flexkit provides an explicit cleanup mechanism.