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.


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?

  • I also have this issue. I'll let you know if I find a fix
    – Hunter
    Oct 20, 2020 at 14:32
  • Can you please explain this ? Which command one by one ? Oct 21, 2020 at 11:18

4 Answers 4


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.


Clear Redis Cache is helpful to me

redis-cli flushall


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.

  • Are there any other types of cache that should just be kept disabled to make quality of life easier?
    – laketuna
    Oct 24, 2020 at 1:42
  • The ones which can directly affect di:compile and even deploy static assets are the mentioned general config cache, and also PHP OPCache (if opcache.validate_timestamps=Off only). Disabling other caches - I haven't had the time to check if it's actually required, so running php ./bin/magento cache:disable is the precautionary step that might not be needed. Oct 24, 2020 at 6:48

Clearing Redis Cache helped for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.