Missing Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory causes setup:di:compile to fail

magento / magento2

Prior to making any Submission(s), you must sign an Adobe Contributor License Agreement, available here at: https://opensource.adobe.com/cla.html. All Submissions you make to Adobe Inc. and its affiliates, assigns and subsidiaries (collectively “Adobe”) are subject to the terms of the Adobe Contributor License Agreement.

http://www.magento.com

Open Software License 3.0

11.5k stars 9.31k forks source link

Missing Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory causes setup:di:compile to fail #24993

Closed twoonesixdigital closed 4 years ago

twoonesixdigital commented 4 years ago

Preconditions (*)

Magento Open Source 2.3.3
Apache 2.4.29
PHP 7.2.19
MySQL 5.7.27
Single Store
Composer installation method
Instance Mode: Developer

Steps to reproduce (*)

Perform a composer magento version update from Magento 2.3.2 to Magento 2.3.3 using a composer.json that requires magento/product-community-edition 2.3.3
Execute the command magento setup:upgrade
Execute the command magento setup:di:compile

Expected result (*)

Magento should recompile and regenerate the required generated code successfully.

Actual result (*)

The Magento executable throws the following error: "In ClassReader.php line 41: Class Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory does not exist"

We found the following models attempting to use the Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory class as parameters in their constructors:

Magento\Usps\Model\Carrier
Magento\Dhl\Model\Carrier
Magento\Dhl\Model\Ups\Carrier

Upon further review, the class Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory does not appear to exist in the codebase. We did however find the class Magento\Framework\Async\ProxyDeferredFactory. We updated the 3 shipping models to use that class rather than the missing class and were able to successfully execute the compile command.

Is this a typo in those shipping models or is Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory truly meant to be a different class than Magento\Framework\Async\ProxyDeferredFactory and it's simply missing from the distribution?

m2-assistant[bot] commented 4 years ago

Hi @twoonesixdigital. Thank you for your report. To help us process this issue please make sure that you provided the following information:

[ ] Summary of the issue
[ ] Information on your environment
[ ] Steps to reproduce
[ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.3-develop instance - upcoming 2.3.x release

For more details, please, review the Magento Contributor Assistant documentation.

@twoonesixdigital do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

[ ] yes
[ ] no

Join Magento Community Engineering Slack and ask your questions in #github channel.

twoonesixdigital commented 4 years ago

@magento give me 2.3-develop instance - upcoming 2.3.x release

magento-engcom-team commented 4 years ago

Hi @twoonesixdigital. Thank you for your request. I'm working on Magento 2.3-develop instance for you

magento-engcom-team commented 4 years ago

Hi @twoonesixdigital, here is your Magento instance. Admin access: https://i-24993-2-3-develop.instances.magento-community.engineering/admin Login: admin Password: 123123q Instance will be terminated in up to 3 hours.

twoonesixdigital commented 4 years ago

As the issue relates to Magento CLI behavior, the vanilla Magento instance testing does not seem relevant nor practical.

m2-assistant[bot] commented 4 years ago

Hi @shikhamis11. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
Details
If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.
[ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.3-develop branch
Details
- Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 5. Add label Issue: Confirmed once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

fascinosum commented 4 years ago

@twoonesixdigital, have you tried to reproduce this issue using recommended flow https://devdocs.magento.com/guides/v2.3/comp-mgr/cli/cli-upgrade.html. Please add an instance mode in the description

fascinosum commented 4 years ago

Magento\Shipping\Model\Rate\Result\ProxyDeferredFactory is auto-generated class

shahbaztariq commented 4 years ago

I see a similar issue but with the following:

Fatal error:  Interface 'Vertex\Tax\Model\Flexfield\Processor\TaxCalculationFlexFieldProcessorInterface' not found in /www/releases/20191012162644/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php on line 24

hostep commented 4 years ago

@shahbaztariq: that's something completely different, you can follow https://github.com/magento/magento2/issues/24930 for that one (there is a patch in there which should fix the problem).

shahbaztariq commented 4 years ago

@hostep thanks for that... I was searching for that but must not have tried hard enough.

Much appreciated!

tiberiucontiu commented 4 years ago

I have exactly the same problem:

The install process uses composer: composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.3.3

Any ideas? Thanks.

tiberiucontiu commented 4 years ago

Figure it out by myself: in my case, some parts of the code were taken from other repo. The di.xml from app/etc/di.xml was not the M233 version but M232. It seems that di.xml in M233 has some relevant changes. So, if your project is created from different repositories - like mine -, make sure both contain the latest M233 code.

twoonesixdigital commented 4 years ago

Figure it out by myself: in my case, some parts of the code were taken from other repo. The di.xml from app/etc/di.xml was not the M233 version but M232. It seems that di.xml in M233 has some relevant changes. So, if your project is created from different repositories - like mine -, make sure both contain the latest M233 code.

Great catch @tiberiucontiu This was my problem as well. You made my day, thank you.

I believe this issue can now be closed. It was indeed a result of a non-standard /app/etc/di.xml file.

webspeaks commented 4 years ago

Figure it out by myself: in my case, some parts of the code were taken from other repo. The di.xml from app/etc/di.xml was not the M233 version but M232. It seems that di.xml in M233 has some relevant changes. So, if your project is created from different repositories - like mine -, make sure both contain the latest M233 code.

It solved the issue for me in Magento 2.3.4-p2. Wonder why this file was not upgraded when I ran composer update? Also there is no mention of it in the official docs!

tiberiucontiu commented 4 years ago

Figure it out by myself: in my case, some parts of the code were taken from other repo. The di.xml from app/etc/di.xml was not the M233 version but M232. It seems that di.xml in M233 has some relevant changes. So, if your project is created from different repositories - like mine -, make sure both contain the latest M233 code.

It solved the issue for me in Magento 2.3.4-p2. Wonder why this file was not upgraded when I ran composer update? Also there is no mention of it in the official docs!

When you run composer update, the files from app/etc, including di.xml, aren't affected. Composer update affects only the vendor/ folder, based on composer.json configuration.

hostep commented 4 years ago

@tiberiucontiu: that's not correct.

When the magento/magento2-base module gets updated using composer, all files from in there are getting copied to the root directory (including that di.xml file), this happens because of this composer plugin: https://github.com/magento/magento-composer-installer Magento calls this process "marshalling".

If the app/etc/di.xml file doesn't get updated, it means an error occurred in the composer plugin and it didn't tell you about it. This might be related to https://github.com/magento/magento2/issues/10292

tiberiucontiu commented 4 years ago

@hostep You're right!

quannguyenbkat commented 3 years ago

Figure it out by myself: in my case, some parts of the code were taken from other repo. The di.xml from app/etc/di.xml was not the M233 version but M232. It seems that di.xml in M233 has some relevant changes. So, if your project is created from different repositories - like mine -, make sure both contain the latest M233 code.

Thank you very much. you save my day