What order should configuration import and module updates be run?

Question

Since the schema version of modules is stored in the key-value storage, it is unique to each site and is not synced through configuration management. That makes sense, since updates may need to make adjustments that are not encapsulated in config (such as database updates), but there are other changes that may also be included in config (e.g. adding a new config value).

• Are there any risks to running config import and database updates in either order?
• What is the preferred order for running those operations?
• Do update hooks need to make any special accommodations for config items that may have already been imported?
• Are there any other operations that may be required to fully update the production environment?

Answer 1

Updates must be run before configuration is imported

A pending issue against core will ensure that the code and schema versions match before allowing configuration to be imported.

---

Problems with config import before updates

• An update hook relying on a configuration value could end in a different result than if it were run on the pre-import value.

• An update could potentially fail if it tried to create configuration entities that already exist.

Concerns for config import after updates

• If an update that introduces a new configuration entity is run first, it will create a new configuration item that will have a differing UUID than the one that is in config. However, once the config is imported the entity should be replaced with the config version.

  There could be a potential problem here if replacing the entity would affect associated content. For example, if an update migrates content from one field to another, on config import the field would be completely replaced and the content potentially lost. In this instance the deployment process may need to be adjusted to run the updates on the target environment and export the resulting configuration.