VirtualCategory with no rules doesn't load in backend (HTTP 500) w/ Medium size catalog

[denis-zyk]

VirtualCategory with no specific rules (i.e. rule value serialised in DB table catalog_category_entity_text looks like {"type":"Smile\\ElasticsuiteVirtualCategory\\Model\\Rule\\Condition\\Combine","attribute":null,"operator":null,"value":"1","is_value_processed":null,"aggregator":"all"}) cannot be loaded in Catalog -> Categories admin backend causing HTTP 500 error.

Preconditions

Magento 2.3.2 CE
ElasticSuite 2.8.1
70k+ products (~74k in our case)
PHP 7.1.32
Redis
MariaDB 10.1.37

Magento Version : 2.3.2 CE

ElasticSuite Version : 2.8.1

Environment : checked in both modes: Developer and Production

Third party modules :
Amasty_BannersLite
Amasty_Base
Amasty_Conditions
Amasty_CommonRules
Amasty_Preorder
Amasty_Rgrid
Amasty_Rules
Amasty_RulesPro
Amasty_ShippingArea
Amasty_Shiprules
Amazon_Core
Amazon_Login
Amazon_Payment
Anowave_Package
Anowave_Ec

Steps to reproduce

1. Go to Catalog -> Categories
2. Click on "Add Subcategory"
3. Set "Virtual category" to "Yes"
4. DO NOT change / add any category rules
5. Save new category
6. Try loading newly created category in backend

Expected result

1. Category loads in the backend (where you can change/configure the category)

Actual result

1. Request fails with HTTP 500 error (reaching max allowed RAM limit)

After trying the same steps as above with smaller number of products (e.g. 500), everything loads with no issues.
Also, when creating VirtualCategory AND setting some category rules at the creation time yields no issues with loading such category afterwards.

[rbayet]

Hello @denis-zyk,

I can somehow reproduce this issue on a CE 2.3.2 + Elasticsuite 2.8.1 with Luma + the medium performance toolkit profile (44k products in the catalog).

What is strange is that :

• there are no errors when initially saving such a category
• there are no errors when the category edit form is displayed again and the switch to virtual category is performed and saved

But indeed, if changing back to the root category and coming back to the category, the error occurs.

But I've managed to display again such a category on and off.
We'll try to be looking for that.

Regards,

Edit: I have the impression that it is something impacted by the cache.

[denis-zyk]

Any updates on this one, @rbayet? How can we fix it, or possibly workaround with the current virtual categories which couldn't be opened in the admin backend anymore?

[rbayet]

Hello @denis-zyk,

This issue has been a bit de-prioritized since we cannot systematically reproduce it.

As a workaround for your categories which are locked, I would advise switching the is_virtual_category attribute value back to 0 directly in the database.

First identify the attribute id :

select * from eav_attribute where attribute_code = 'is_virtual_category' \G
*************************** 1. row ***************************
   attribute_id: [ATTRIBUTE_ID]
 entity_type_id: 3
 attribute_code: is_virtual_category
attribute_model: NULL
  backend_model: NULL
   backend_type: int
  backend_table: NULL
 frontend_model: NULL
 frontend_input: NULL
 frontend_label: Is virtual category
 frontend_class: NULL
   source_model: NULL
    is_required: 0
is_user_defined: 0
  default_value: 0
      is_unique: 0
           note: Is the category is virtual or not ?

Then delete or change the value for that attribute for any problematic category :

DELETE FROM catalog_category_entity_int WHERE attribute_id = [ATTRIBUTE_ID] AND entity_id = [YOUR_CATEGORY_ID] LIMIT 1

or

UPDATE catalog_category_entity_int SET value = 0 WHERE attribute_id = [ATTRIBUTE_ID] AND entity_id = [YOUR_CATEGORY_ID] LIMIT 1

Regards,

[rbayet]

Hi @denis-zyk,

Are you definitely positive that you also face the issue in production mode ?
Because so far, I only have manage to reproduce this in developer mode.

Regards,

[rbayet]

Caused by aggs. resolving refactoring and #1458 which re-introduced the legacy behavior of the pageSize handling in the collection : \Smile\ElasticsuiteCatalog\Plugin\Ui\Category\Form\DataProviderPlugin::getAttributes generates a fulltext collection loading of all valid products.

[rbayet]

Hi @denis-zyk,

Are you definitely positive that you also face the issue in production mode ?
Because so far, I only have manage to reproduce this in developer mode.

Regards,

Looking back on it, it's probably the overhead of the developer mode that makes it "faster" to occur with regards to the catalog size.
Please ignore @denis-zyk.

Regards,