[CatalogImportExport] Static attribute cleaning asynchronously #39585
Labels
Reported on 2.4.7
Indicates original Magento version for the Issue report.
Triage: Dev.Experience
Issue related to Developer Experience and needs help with Triage to Confirm or Reject it
Preconditions and environment
Actually, I don't have much to reproduce, I just know the technical cause of the error but it's related to garbage collector so it's a bit tricky to reproduce depending on the PHP settings, the amount of modules loaded by the magento instance...
Steps to reproduce
For more context, I'm using a custom module in addition of https://github.com/firegento/FireGento_FastSimpleImport2
This module is using magento product import model \Magento\CatalogImportExport\Model\Import\Product
Numerous instances of the model are created because we have low memory context.
Error is related to \Magento\CatalogImportExport\Model\Import\Product\Type\AbstractType::__destruct()
The thing is that the garbage collector calls the destructor of this class a bit randomly when it requires memory.
And the call of this destructor has an impact on all existing classes child of \Magento\ImportExport\Model\Import\Entity\AbstractEntity
In my case, I encountered and trace the error because the destructor was called between 2 internal call of the class :
Here is the result I got during my calls
I added log at the end of the attachAttribute function, in the destructor of the class and just after the attachAttribute call.
The destructor was being called multiple times (For multiple existing instances I suppose) between the return log and the aftercall log
The two logs where both (destructor call log is obvious):
Expected result
The static variables used by a given object during its lifetime must not be modify by the destructor of any other object.
Knowing the randomness of the PHP garbage collector, this is even more risky.
Actual result
The destructor call is cleaning the static caches makes the import process completely random if numerous instances of the classes are allocated and released.
Additional information
Here is the exception log of the error I faced but I had to dig for another couple of hours to find the cause of it :
Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: