Does Drupal 10 core config sync resolve field storage schema drift?

Answer to the core question

Drupal 10’s core configuration synchronization does not merge divergent field‑storage schemas. If the field_storage_config for a field differs between environments, the sync will abort with an error such as “Field storage configuration conflict” and will not automatically reconcile the difference.

Why the conflict happens

• Field storage is stored in field_config and field_config_instance tables.
• When a field is defined in a module, the module’s YAML is considered the single source of truth.
• Manual database edits or different module code across environments create a schema drift that core sync cannot resolve.

Confirmed mechanisms to avoid manual DB changes

1. Isolate field storage in a Config Split
   Use the Config Split module to create a split that excludes field_storage_config and field_config_instance from the sync on dev and staging. Import the split only on production where the schema is expected to match.
2. Use config_ignore (if available)
   Some setups allow config_ignore to skip specific config types during sync. This keeps the field storage out of the sync cycle, preventing drift but also keeping the field absent on environments where it should exist.
3. Re‑export the field definition from the authoritative module
   Ensure that the module providing the field is identical on all environments. Then run drush config:export on the source, copy the YAML to the target, and import.
4. Use drush config:import --partial
   When you know the field storage is correct on the target, import only the field instance configs and skip storage.

Using Config Split reliably

• Create a split named prod-field-storage that includes only field_storage_config.* and field_config_instance.*.
• Apply the split on production only: drush config:split:import prod-field-storage.
• On dev/staging keep the split disabled so that any drift is caught before reaching prod.
• After importing, run drush config:status to confirm the field is present and the schema matches.

What to do if drift persists

If the field still fails to import, it may be because the module that defines it has diverged or because manual database edits introduced an incompatible schema. In that case, you should:

1. Verify that the module code is identical across environments.
2. Check the database tables field_config and field_config_instance for mismatched column definitions.
3. Re‑create the field via the UI or a migration script to ensure consistency.

One diagnostic detail that could change the recommendation

Could you confirm whether the drift is caused by a module that defines the field (e.g., a custom module that differs between environments) or by a manual database edit that introduced a new column or altered a type?

Practical verification steps

• Run drush config:diff --source=dev --destination=prod to see exactly which field‑storage YAML differs.
• After applying a split, create a node of the content type that uses the field and verify the field renders correctly.
• Inspect the database tables for the field’s storage definition to ensure it matches the YAML.