Magento2: Backward-incompatible change from 2.1.2 to 2.1.3 on Config Reader

[romainruaud]

On the ElasticSuite module, we had a virtualType built with using \Magento\Store\Model\Config\Reader\ReaderPool :

    <virtualType name="Smile\ElasticsuiteCore\Model\Search\Request\RelevanceConfig\ReaderPool" type="Magento\Store\Model\Config\Reader\ReaderPool">
        <arguments>
            <argument name="readers" xsi:type="array">
                <item name="default" xsi:type="object">Smile\ElasticsuiteCore\Model\Search\Request\RelevanceConfig\Reader\DefaultReader</item>
                <item name="container" xsi:type="object">Smile\ElasticsuiteCore\Model\Search\Request\RelevanceConfig\Reader\Container</item>
                <item name="containers" xsi:type="object">Smile\ElasticsuiteCore\Model\Search\Request\RelevanceConfig\Reader\Container</item>
                <item name="containers_stores" xsi:type="object">Smile\ElasticsuiteCore\Model\Search\Request\RelevanceConfig\Reader\ContainerStore</item>
                <item name="container_store" xsi:type="object">Smile\ElasticsuiteCore\Model\Search\Request\RelevanceConfig\Reader\ContainerStore</item>
            </argument>
        </arguments>
    </virtualType>

This file was moved to Framework by this commit :

https://github.com/magento/magento2/commit/11149f8144444d0442022fd91ce5ff98c803fc7a#diff-3fbbbd1a4273b6fc4feac789d0412b71

This introduce a backward incompatible change : we have customers using this module that are still on 2.1.2 (or lower) and that do not plan to migrate immediately.

We could change the type of the item used from Magento\Store\Model\Config\Reader\ReaderPool to the new one Magento\Framework\Config\ReaderPool but it won't work on prior versions than 2.1.3.

Imho you should have kept the Magento\Store\Model\Config\Reader\ReaderPool for backward compatibility. Maybe just keep it as an empty class and set as deprecated, but definitely not removed it.

Best regards,

[vishveskrish]

Hey @romainruaud ,

We are facing same issue while upgrade to 2.1.3 from 2.1.2.

It is not allowing me to upgrade "php bin/magento setup:upgrade".
Here is the error,
[RuntimeException]
Source class "Magento\Store\Model\Config\Reader\ReaderPool" for "Magento\
Store\Model\Config\Reader\ReaderPool\Proxy" generation does not exist.

Let me know if anyone find the solution.

[imgali]

Same here on 2.1.3

[DavidLambauer]

Same here

[FicoSvt]

It was the same here as well. We found out that this is related to php generation failure.

Try to manually delete everything from var/cache and var/generation directories. After you do it, you should be able to run php bin/magento setup:upgrade without further issues.
Hope this helps.
Cheers

[antonkril]

@DavidLambauer, @imgali do you face the code level issue described by @romainruaud or the upgrade issue described by @vishveskrish? Did you use \Magento\Store\Model\Config\Reader\ReaderPool in your code?

@romainruaud, \Magento\Store\Model\Config\Reader\ReaderPool did not have @api annotation, so we did not treat it as a part of our public API. Did you use it to reuse the getReader method, or to inherit the reader list?

[imgali]

@antonkril we face the same issue described by @vishveskrish

We did not utilize Magento\Store\Model\Config\Reader\ReaderPool in our code, nor were any of our modules. The issue only occurred on a local environment. It never occurred in Production Environment. I deleted var/cache and generation directories and restarted the vagrant instance which solved the problem.

[romainruaud]

Hello @antonkril and thank you for answering.

We did explicitely use the ReaderPool class. We did it because the class was provided by Magento.

Our main problem is that we did use it for a virtualType : we were forced to use the class explicitely and not the interface it implements, which would have be transparent when you decided to move the class.

However, since we are speaking about an open source software, anybody can use any class where he wants to, even if this is sometimes not a good practice. In consequence, we were so surprised that you decided to move this class arbitrary without letting it on the previous location : with an empty class inheriting the new one, and marked as deprecated.

We refactored the piece of code using this class, so this is not anymore a problem for us, but imho it's mainly a philosophical concern about extensibility and non-breaking changes.

Best regards,

[vishveskrish]

Hey @antonkril ,

We did not utilize Magento\Store\Model\Config\Reader\ReaderPool in our code, nor were any of our modules.

[antonkril]

@vishveskrish, @imgali, @FicoSvt, @DavidLambauer, the issue you encountered is related to upgrade flow documentation. var/generation folder depends on specific codebase, so it should be cleared every time you deploy new codebase, including upgrades. This was not mentioned in our documentation. We added it now: http://devdocs.magento.com/guides/v2.0/comp-mgr/cli/cli-upgrade.html#ui-id-5.

@romainruaud, Magento 2 team promises backwards compatibility only for public API (@api annotated code). We try to minimise changes in our private (non-API) code too, but sometimes we have to break it. Our Backwards Compatibility policy is described here: http://devdocs.magento.com/guides/v2.1/extension-dev-guide/backward-compatibility.html

We decided not to keep old classes when we move code around, because:

1. it would lead to significant amount of unused code left in codebase
2. it would be misleading for some customisations as plugins on such old classes would stop working, because these old classes would never be called in our system

We understand that our @api coverage is limited for now, and plan to increase it in 2.2
We also understand that some extensions and customisations will have to use our private code. In such cases we recommend to depend on full version of used module (100.2.3, not 100.*.*) in your composer.json.

From the code snippet you provided It is hard to understand why you needed this specific Magento\Store implementation of ReaderPool.

[romainruaud]

Hello @antonkril and thank you for this detailed answer.

We (people of Smile Group) understand your policies about @api and backward compatibility. However, this principle is not totally bad, but clearly does not cover enough code atm : if we should rely only on @api annotated code to develop module for now, we are not able to produce a fully-covered code and are exposed to breaking changes during at each version upgrade.

Glad to see that you plan to increase coverage of @api code in next 2.2 version.

Regarding your workaround which consists into depending on full version of used module, I'm afraid but I think this is irrelevant (and therefore a bad practice) when developing extensions modules because it can imply critical issues when integrating several community modules into a project.

E.g, imagine a project using the following modules :

• module A : require magento/catalog 100.2.3
• module B : require magento/catalog 100.2.1

I have not tested this case, but I guess this would be impossible to do, so this is not reliable for us since we publish extensions module and do not want to stick our customer to a given version of core modules.

Also, suppose we add a strong dependency to magento/catalog 100.2.1 into our module, how could we ensure that all other core modules depending on the last version of magento/catalog will continue to work properly ?

Best regards,
Given this case, how

[rbostan]

Same in 2.1.2 to 2.1.7.
Is there fix for this ?

[cherreman]

We had this issue when upgrading from 2.1.2 to 2.1.7. When executing the setup:upgrade command, we got the error:

[RuntimeException]
Source class "Magento\Store\Model\Config\Reader\ReaderPool" for "Magento\
Store\Model\Config\Reader\ReaderPool\Proxy" generation does not exist.

We tried cache:flush but the command would not run with the same error. We ended up flushing the Redis db via redis-cli. After that the upgrade and compile command ran as expected.

[vishveskrish]

Hi @cherreman ,
Just clear the var/cache and var/generation folder and try to run upgrade command again.

[cherreman]

@vishveskrish We tried that, but it didn't work.

[rbostan]

Still same in 2.1.2 to 2.1.8 :)
Is there fix for this ?

[gelanivishal]

Please run below command in magento root directory.

composer install

[magento-engcom-team]

@romainruaud, thank you for your report.
This seems to be correct Magento behavior. Please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this.
Otherwise you may submit Pull Request with the suggested changes.