Update 2.3.2->2.3.3 Fails on magento setup:di:compile with an error mentioning InvoiceFlexFieldProcessorInterface

[thomvanderboon]

Update 2.3.2 -> 2.3.3 fails with error during magento setup:di:compile

Preconditions (*)

1. Magento 2.3.2
2. PHP 7.2
3. MariaDB 10.3

Steps to reproduce (*)

1. composer require magento/product-community-edition=2.3.3 --no-update
2. composer update
3. php bin/magento setup:upgrade
4. php bin/magento setup:di:compile
5. composer dump-autoload -o

Expected result (*)

No errors during update

Actual result (*)

PHP Fatal error: Interface 'Vertex\Tax\Model\Flexfield\Processor\InvoiceFlexFieldProcessorInterface' not found in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php on line 24

[m2-assistant]

Hi @thomvanderboon. 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.

@thomvanderboon 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.

[thomvanderboon]

I might have solved the problem by accident. While investigating it looks like I found a working solution.

At the end of the "use" clauses in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php add the following two lines:

use Vertex\Tax\Model\FlexField\Processor\InvoiceFlexFieldProcessorInterface;
use Vertex\Tax\Model\FlexField\Processor\TaxCalculationFlexFieldProcessorInterface;

[m2-assistant]

Hi @sudheers-kensium. 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: 👇

• 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.

[sudheers-kensium]

@thomvanderboon Issue is not reproducible, so I am closing this.

[navarr]

Attached is a patch that should resolve this issue.

vertex-compilation-issue.patch.txt

[vkublytskyi]

@thomvanderboon Thank you for reporting an issue.

May you describe your environment (OS, PHP version, do you use some Docker or Vagrant, etc.)?Seems issue affects only several environments and we are trying to understand what exactly environments are affected.

[ghost]

Just ran into this issue with a client's site. It's a Kubernetes environment, Ubuntu, PHP 7.2.22.

[thomvanderboon]

@vkublytskyi

Multishop Magento environment with two languages installed.

VMware Virtual Server (plain, no docker, vagrant etc.)
Ubuntu 18.04 LTS (daily patched to latest level)
php7.2/bionic,bionic,now 7.2.23-1+ubuntu18.04.1+deb.sury.org
Imagemagic instead of GD2
No Varnish or other external cache
Luma theme

For "compiling" magento I run following commands:

rm -rf var/cache/*
rm -rf var/page_cache/*
rm -rf generated/code/*
php ../composer.phar update
php bin/magento setup:upgrade
php bin/magento setup:di:compile
composer dump-autoload -o
composer clear-cache

[MarcusWolschon]

Attached is a patch that should resolve this issue.

vertex-compilation-issue.patch.txt

Cool.
So we wait until a release of vertex/tax is made containing the patch and then run composer again?
Or can we apply the patch and composer will not cause any trouble in later updates since the file checksum has changed or since this patch can't be applied twice?

[hostep]

I'm going to re-open this ticket for now, just because a lot of people are creating duplicates of this issue and having one open ticket might prevent them from doing so :)
We can close it once an official solution is in place and when we have a timeline for when it will become available.

@navarr: is Magento still sticking to their "let's only allow one specific version of a core-bundled-extension to be included in a specific version of Magento", or is there a way to release a new version of Vertex without having to wait on Magento 2.3.4 ?

[shahbaztariq]

I might have solved the problem by accident. While investigating it looks like I found a working solution.

At the end of the "use" clauses in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php add the following two lines:

use Vertex\Tax\Model\FlexField\Processor\InvoiceFlexFieldProcessorInterface;
use Vertex\Tax\Model\FlexField\Processor\TaxCalculationFlexFieldProcessorInterface;

This fix works for me. I was not able to successfully apply the patch given above. This only started happening after I upgraded from 2.3.2 to 2.3.3

Ubuntu 16.04.6 LTS
Magento 2.3.3
PHP 7.2.23
MySQL 5.7.27
Redis 5.0.6
Varnish 4.1.1

[robsoned]

I might have solved the problem by accident. While investigating it looks like I found a working solution.
At the end of the "use" clauses in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php add the following two lines:
use Vertex\Tax\Model\FlexField\Processor\InvoiceFlexFieldProcessorInterface;
use Vertex\Tax\Model\FlexField\Processor\TaxCalculationFlexFieldProcessorInterface;

This fix works for me. I was not able to successfully apply the patch given above. This only started happening after I upgraded from 2.3.2 to 2.3.3

Ubuntu 16.04.6 LTS
Magento 2.3.3
PHP 7.2.23
MySQL 5.7.27
Redis 5.0.6
Varnish 4.1.1

I had the same problem here on a fresh installation and the above solution worked for me.

Debian GNU/Linux 9
Magento 2.3.3
PHP 7.1.30
MySQL 5.7.25

[crdt]

I might have solved the problem by accident. While investigating it looks like I found a working solution.

At the end of the "use" clauses in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php add the following two lines:

use Vertex\Tax\Model\FlexField\Processor\InvoiceFlexFieldProcessorInterface;
use Vertex\Tax\Model\FlexField\Processor\TaxCalculationFlexFieldProcessorInterface;

I had the same problem too and the above solution worked for me.

Debian GNU/Linux 9.9
Magento 2.3.3
PHP 7.2.23
MariaDB 10.1.41

[vkublytskyi]

@shahbaztariq, @robsoned, @crdt instead of code modification in a vendor folder it should be possible to fix the issue with running composer dump-autoload -o before and after magento setup:di:compile

[thomvanderboon]

Commands:
composer dump-autoload -o
magento setup:di:compile
composer dump-autoload -o

Result:

Generating optimized autoload files
Compilation was started.
Repositories code generation... 1/7 [====>-----------------------] 14% 1 sec 80.5 MiBPHP Fatal error: Interface 'Vertex\Tax\Model\Flexfield\Processor\InvoiceFlexFieldProcessorInterface' not found in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php on line 26
Generating optimized autoload files

No fix...... :(

[m2-assistant]

Hi @engcom-Delta. 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: 👇

• 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.

[thomvanderboon]

whilst it should be:

namespace Vertex\Tax\Model\FlexField\Processor;

Tested this solution on my system and it works. Second capital F seems to be the "error" and solution.

[hostep]

Well, yes, that's what the patch posted days ago says as well 😉

[janmyszkier]

sigh can't wait for the MacOS developers to come to their senses and start using case-sensitive filesystem (and Windoze developers to stop using windows for development until it provides case sensitive file system)

[navarr]

@janmyszkier: PHP namespaces are case-insensitive.

While I definitely take full blame for the issue, I think it might be a corner-case composer or DI bug

[shahbaztariq]

Whilst that may be true - we should definitely work in a case-sensitive environment.

On linux this is the case already.

On OSX there is a way to create a disk image that is built on a case sensitive file system and works very well.

On windows however, no idea.

[vkublytskyi]

@janmyszkier Unfortunately this issue is more tricky than just case sensitive/insensitive filesystems. We do have a testing infrastructure verifying builds on various Linux distros as well as before release we made manual regression on various environments including Magento Cloud and on all of these environments the issue does not appear. So we still exploring issue and try to find a reason for different behavior on different environments.

[jcoby]

@janmyszkier: PHP namespaces are case-insensitive.

While I definitely take full blame for the issue, I think it might be a corner-case composer or DI bug

while php is case-insensitive, PSR-4 is not:

The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name.

So, while php doesn't care about Flexfield vs FlexField, PSR-4 and composer do.

[vkublytskyi]

We will add static tests to enforce strict case comparisons for PHP code and DI configuration to avoid such issues in the future.

[pierzakp]

Faced this issue as well, anyone knows any ETA when it will be solved?

[vkublytskyi]

@pierzakp, unfortunately, we cannot modify code after it was released and the extension bundling mechanism does not allow change version of the bundled extension. Therefore, the best way, for now, is applying a patch provided by @navarr. For sure, Magento 2.3.4 release will have fixed this issue.

Magento recently also released a security patch release 2.3.2-p2 which contains a lot of security fixes and not affected by this bug.

[MarcusWolschon]

@pierzakp, unfortunately, we cannot modify code after it was released

So... why not release a 2.3.3-p1 ?

[shahbaztariq]

Can we not have a patch similar to the patches described here: https://devdocs.magento.com/guides/v2.3/release-notes/release-notes-2-3-3-open-source.html

• Apply the Catalog pagination issue on Elasticsearch 6.x patch to resolve a critical search result pagination issue
• Apply the EmailMessageInterface backward compatibility issue patch to resolve an email interface backward-incompatibility issue
• Apply the Method chaining fix for product collection patch to resolve an issue with broken method chaining in some extensions

[davidalger]

@janmyszkier

sigh can't wait for the MacOS developers to come to their senses and start using case-sensitive filesystem (and Windoze developers to stop using windows for development until it provides case sensitive file system)

Adding to what @vkublytskyi already said, the issue is definitely more complicated than the case-sensitivity of a file system. As long as the FS on a docker containers (yes, even on Docker for macOS!) is not mounted into the container from the host, the FS is actually case-sensitive since the FS is case-sensitive inside the VM which Docker Desktop runs within. Yet, the DI compilation issue doesn't show up there within the case-sensitive docker volume when running on Docker Desktop for macOS.

I first ran across this issue on a Github Action which I have to build Magento demo images after each new version is released, and nobody else on my team could replicate, so I dug deeper and ran the same container image build on Docker Desktop for MacOS, Fedora 30, CoreOS 2191.5.0 (stable), Ubuntu 16.04 and Ubuntu 18.10 and it builds the image successfully on all of these. But it fails when you build this same container image (which executes the DI compile) with docker on Fedora 29 and a Github Actions pipeline. Everything except for the macOS test was run on a completely clean OS install spun up on a Digital Ocean droplet. I hope you can see the disparity there! In every case (including the image build on macOS) the DI compile was running on a case-sensitive FS, yet it only failed in 2 out of 7 host OS environments. Why? I have no idea…my guess since I was reproducing in a docker container is something to do with version of the docker engine.

[davidalger]

@vkublytskyi @navarr If Vertex could publish a dot release fixing the namespace, it would be super simple to use the correct version on 2.3.3 allowing DI to compile for those affected:

composer require "vertex/module-tax 3.2.1 as 3.2.0"

The above command would result in composer installing (the currently unreleased) version 3.2.1 instead of 3.2.0 overriding the sub-package dependencies. Simple, no patches, and it would work if a version 3.2.1 of vertex/module-tax could be released on the marketplace.

[ralbin]

I had to adjust the patch to work with being installed with composer. I attached it here.
vendor-vertex-compilation-issue.patch.txt

[jonathan-martz]

I have the same Problem while updating magento to 2.3.3.
Would be real nice if somebody can fix this small Problem aka. Typo.

[navarr]

This issue is fixed in Vertex 3.3.0 included in Magento 2.3.4

[janmyszkier]

@navarr , @vkublytskyi , @davidalger
Yes this is not the definitive solution, but would definitely make them aware filename case is important since they would face it daily and have problems when not following the rules. That was the main idea behind the switch all along.

@vkublytskyi
I'm happy to hear this will be forced now. Will there be post-update composer hook to enforce app/code and vendor package compliance?

[ghost]

I just got this error out of the blue. Earlier in the day, by CircleCI workflow ran fine, with zero issue. One commit later, adding files into a custom module in app/code and this error pops up when trying to do setup:di:compile. Literally no reason for it to kick off, when it didn't previously.

[dsmithhayes]

Has there been any progress on this at all? It's January 2020 and I have been trying to upgrade from Magento 2.2.9 to 2.3.3 and this breaks the dependency injection compilation. I find it unacceptable a small typo causing such a bug would remain in a production codebase for so long. I have resorted to forking the Vertex module and pushing the fix myself for my team.

[navarr]

@dsmithhayes A patch was provided earlier in the comments: #24930 (comment) - a fix will be delivered with 2.3.4

[jonathan-martz]

Nice.
Looks like this could by closed soon.

[hostep]

The fix will also be part of the security release 2.3.3-p1 (will be released together with 2.3.4, public release is 28 January), which is rather odd as it has nothing to do with security, but anyways, it's good Magento is doing this I think.

$ diff -urw magento233/vendor/vertex/ magento233-p1/vendor/vertex/
diff -urw magento233/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php magento233-p1/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php
--- magento233/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php 2019-09-10 10:09:26.000000000 +0200
+++ magento233-p1/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php  2020-01-07 07:53:48.000000000 +0100
@@ -4,7 +4,7 @@
  * @author     Mediotype                     https://www.mediotype.com/
  */

-namespace Vertex\Tax\Model\Flexfield\Processor;
+namespace Vertex\Tax\Model\FlexField\Processor;

 use Magento\Framework\Exception\NoSuchEntityException;
 use Magento\Quote\Api\CartRepositoryInterface;
diff -urw magento233/vendor/vertex/module-tax/composer.json magento233-p1/vendor/vertex/module-tax/composer.json
--- magento233/vendor/vertex/module-tax/composer.json  2019-09-10 10:09:26.000000000 +0200
+++ magento233-p1/vendor/vertex/module-tax/composer.json   2020-01-07 07:53:48.000000000 +0100
@@ -3,7 +3,7 @@
     "description": "Vertex Tax Links for Magento 2",
     "type": "magento2-module",
     "license": "proprietary",
-    "version": "3.2.0",
+    "version": "3.2.1",
     "require": {
         "php": "^7.0",
         "ext-soap": "*",

[borisFuentesCisterna]

ESO FUNCIONO PARA MI
I might have solved the problem by accident. While investigating it looks like I found a working solution.

At the end of the "use" clauses in /path to website/vendor/vertex/module-tax/Model/FlexField/Processor/OrderCurrencyGetterProcessor.php add the following two lines:

use Vertex\Tax\Model\FlexField\Processor\InvoiceFlexFieldProcessorInterface;
use Vertex\Tax\Model\FlexField\Processor\TaxCalculationFlexFieldProcessorInterface;

This fix works for me. I was not able to successfully apply the patch given above. This only started happening after I upgraded from 2.3.2 to 2.3.3