Fix: 'Cannot instantiate interface Magento\Eav\Api\AttributeRepositoryInterface' on Magento 2.4.8-p3 setup:upgrade

What the error actually means

The trace begins inside Magento’s ObjectManager:

There is an error in /app/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php at line: 50
Cannot instantiate interface Magento\Eav\Api\AttributeRepositoryInterface
#0 .../ObjectManager.php(73): Developer->create('Magento\\Eav\\Api...')
#1 .../AbstractFactory.php(170): ObjectManager->get('Magento\\Eav\\Api...')
#2 .../AbstractFactory.php(276): AbstractFactory->resolveArgument(Array, 'Magento\\Eav\\Api...', NULL, 'attributeReposi...', 'Magento\\Catalog...')

Read the stack from bottom to top: a constructor argument typed AttributeRepositoryInterface $attributeRepository needs a concrete implementation. The ObjectManager looks up its preferences map (the merged result of every module’s etc/di.xml), expects to find a mapping to Magento\Eav\Model\AttributeRepository, and instead is told “just build the interface directly.” PHP cannot instantiate an interface — so it throws.

That mapping does still exist in vendor/magento/module-eav/etc/di.xml in 2.4.8-p3. So why does Magento not see it? Because Magento is not reading di.xml at runtime — it is reading the compiled result from your previous version’s generated/ tree.

Why this happens on a 2.4.7-p3 → 2.4.8-p3 upgrade

Three pieces of state survive a composer install:

• generated/code — compiled proxies, factories, and interceptors keyed to the old class graph.
• generated/metadata — the compiled DI configuration (the merged di.xml from the previous build).
• var/cache + var/page_cache — warmed Redis/file caches that include the old config dump.

When Adobe ships a patch release that touches DI — new arguments on a constructor, a refactored preference, a removed virtual type — the new vendor/ code expects a fresh map. The old compiled map has a hole where the new constructor argument resolution lands, and the ObjectManager falls through to create(InterfaceName) instead of create(ConcreteClass). The fix is to throw the stale compiled state away and let Magento rebuild it.

The fix (copy-paste, in order)

From your Magento root, with the new vendor/ already installed by composer install:

# 1. Wipe every piece of stale state
rm -rf generated/code generated/metadata
rm -rf var/cache var/page_cache var/view_preprocessed var/di

# 2. Re-dump the autoloader so Composer maps the new vendor tree fresh
composer dump-autoload

# 3. Re-run the upgrade
bin/magento setup:upgrade

# 4. Production hosts only: compile DI + redeploy static + flush cache
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f en_US
bin/magento cache:flush

That is the whole recipe. On developer-mode local stores, steps 1–3 are enough — missing generated classes are built on the next request. On production hosts, you must run step 4 or the storefront renders without DI-compiled interceptors and with stale assets.

If the same error returns after the wipe

If setup:upgrade still throws “Cannot instantiate interface AttributeRepositoryInterface” on the rebuilt generated/ tree, the problem is no longer stale state — one of your installed extensions is overriding the EAV preference with a class that no longer exists. Run this audit:

# Find every <preference> against the AttributeRepositoryInterface across
# vendor + app/code so you can see which module last claimed it.
grep -R --include='di.xml' \
  'AttributeRepositoryInterface' \
  app/code vendor/*/module-* vendor/*/*-module 2>/dev/null

# Same search, but for any EAV-API interface (broader net for related errors)
grep -R --include='di.xml' \
  'Magento\\Eav\\Api\\' \
  app/code vendor 2>/dev/null

Walk the matches. Anything outside vendor/magento/ that points AttributeRepositoryInterface at a custom class is the suspect. Two common shapes:

• Removed class in the preference target. The vendor refactored their plugin in a recent release and dropped the override class, but did not remove the <preference> tag.
• Class extends a removed parent. The override class still exists but extends a Magento parent that Adobe deleted in 2.4.8. PHP autoload fails before the constructor is even reached.

Disable that extension in app/etc/config.php (set its value to 0), re-run the upgrade, confirm the error is gone, then file a compatibility ticket with the extension vendor.

Related errors that share this root cause

The same recipe recovers Magento from several differently-worded failures — all of them flavors of “ObjectManager has a stale view of the world”:

Make this less painful next time

The cleanest long-term fix is to stop relying on the host’s generated/ tree being correct across upgrades. Two changes pay for themselves:

• Build → deploy pipeline. Run composer install, setup:di:compile, and setup:static-content:deploy in a fresh build container, package the resulting vendor/ + generated/ + pub/static/, and rsync the package to production. The live host never compiles — it only swaps in a known-good artifact.
• Use --keep-generated on deploy. If your build step already produced generated/, run bin/magento setup:upgrade --keep-generated so the upgrade does not discard the freshly compiled tree.

For a deeper look at what each phase of setup:upgrade actually does — declarative schema, the patch_list / setup_module tables, and the difference between developer and production mode — see What Magento setup:upgrade Actually Does. For the broader catalogue of universal upgrade traps (PHP, composer, Hyvä theme, indexer), see Magento 2.4.9 upgrade issues: 5 universal traps.