Missing mapping in di.xml after upgrading 2.4.0 to 2.4.1

Question

The app breaks completely after upgrading a working 2.4.0 to 2.4.1 using instructions from https://devdocs.magento.com/guides/v2.4/comp-mgr/cli/cli-upgrade.html.

Steps:

composer require magento/product-community-edition 2.4.1 --no-update
composer update
rm -rf var/cache/*
rm -rf var/page_cache/*
rm -rf generated/code/*
bin/magento setup:upgrade

setup:upgrade errors out with the following message, and the entire M2 instance (web and CLI) is broken.

Fatal error: Uncaught Error: Cannot instantiate interface Magento\MediaContentSynchronizationApi\Model\GetEntitiesInterface in /var/www/html/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php:50

Upon inspecting app/etc/di.xml, I see no mapping for Magento\MediaContentSynchronizationApi\Model\GetEntitiesInterface.

It seems to me the composer require and update does not update di.xml correctly, but I'm not sure. Any idea how to upgrade to 2.4.1?

Answer 1

This problem is related to the ElasticSearch requirement and it not being properly setup during the upgrade.

I found it best to just: Before you pull down latest code and run setup:upgrade, disable all ElasticSearch:

php bin/magento module:disable {Magento_Elasticsearch,Magento_InventoryElasticsearch,Magento_Elasticsearch6,Magento_Elasticsearch7} 

Then get latest code, perform the setup:upgrade and visit admin; make sure all works. Then enable ElasticSearch but ignore the setup:upgrade. Go into Admin and properly setup the ES; then save. Now all will work.

Sometimes php bin/magento will not work because of that, so it is neccesary to disable ES modules manually from app/config.php and then flush the cache manually

If you tried this and still get the error; make sure that when you disabled the ES; that you completely flushed all cache (and any redis) and deleted any generated files etc.

Answer 2

Depending on how you got caches set up (PHP OPCache, Redis, etc.), the configuration cache data may end up interfering with the new code.

The bulletproof way to deal with issues like this is to disable configuration cache prior to di:compile.

Another gotcha, is disabling config cache with php ./bin/magento cache:disable might likewise fail because ./bin/magento errors with similar messages.

So to resolve this reliably, you would resort to things like sed to disable config cache:

# important step: disable general config cache with sed!
sed -i "s@'config' => 1@'config' => 0@" ./app/etc/env.php

# disables remaining caches
php ./bin/magento cache:disable

# compilation
php ./bin/magento setup:di:compile

# re-enable back all the caches
php ./bin/magento cache:enable

P.S. all in all, this is a design flaw of Magento 2. di:compile should not be using any caches, but, alas, it does, and thus this crucial step of Magento deployment is very much faulty unless caches are disabled prior to running it.

Answer 3

Clearing Redis Cache helped for me.

Answer 4

Clear Redis Cache is helpful to me

redis-cli flushall