If an update hook modifies configuration, then old configuration is imported, the changes made by the update hook are forever lost.

This issue recently affected us with the release of Drupal 10.1. 📌 Replace custom password hashing library with PHP password_hash() Fixed included an update hook to enable the new phpass core module. Once that update hook ran the module was enabled only to be disabled when config import was subsequently run.

We have automated tests that check the status of Drupal config state, but these did not fail because once config:import had run (via drush deploy), the configuration on disk matched the active configuration as far as Drupal was concerned.

If we are allowing folks to believe that configuration on disk is their source of truth and then modifying active configuration with an update hook, this seems like it will inevitably cause issues like this.

It seems to me like there's a fundamental contradiction to running database updates and configuration updates all in a single action.

It's already very complicated to wrestle with the concept of "correct configuration" when you have site administrators making configuration updates and developers making configuration updates in parallel.

What if configuration updates in code were given special treatment? We could have a separate one-time operation from updb [hook_install_configuration_N(): returns an array of configuration files to be re-imported from a module's /config/*/ directories; is triggered by 'drush update-configuration' or visiting /update-config.php]

Then, the "best practice" could be:
1. updb
2. cim
3. upcfg

(and then: export that config into code!)

If we tracked the executed upcfg functions in their own table with a date or "invocation" column, we could provide a way to "re-run" an invocation if a site accidentally ran CIM after upcfg.

At Lullabot, we wrote up an Architecture Decision Record (ADR) to deal with a similar situation.

https://architecture.lullabot.com/adr/20210924-drupal-build-steps/

Depends on developers using hook_post_update_NAME() → .

Does that help?

A PR is in progress for drush deploy to catch this problem and stop the deployment - https://github.com/drush-ops/drush/pull/5713