In optimizers preview in admin panel optimizers are not filtered properly

[sevka]

During new optimizer creation (or editing) in admin panel, if I click the "Preview" button, the wrong search result appears in both "Base Results" and "Optimized Results" columns. The product list differs from the products list on the search result page on the Frontend.
I debugged it and found this:
\Smile\ElasticsuiteCatalogOptimizer\Model\Optimizer\Search\OptimizerFilter::getOptimizerIds()
\Smile\ElasticsuiteCatalogOptimizer\Model\Optimizer\Category\OptimizerFilter::getOptimizerIds()
There are conditions like this:
if ($this->searchContext->getCurrentSearchQuery()) {
and
if ($this->searchContext->getCurrentCategory()) {

They never return true, so getOptimizerIds() always return null. Then here
\Smile\ElasticsuiteCatalogOptimizer\Model\Optimizer\ApplierList::applyOptimizers
at this line optimizers are never filtered:
$functions = array_intersect_key($functions, array_flip($optimizerIds));
Elasticsuite doesn't respect the query text and selected category during the Preview from admin panel. When I search from the Frontend, everything is fine.
For me, it looks like a bug. Could you advise, please? Maybe it's a feature I do not get ;)

Preconditions

Magento Version : 2.3.3.

ElasticSuite Version :
I faced the issue on 2.8.4, but I've reproduced it on latest 2.8.7 as well.

Environment :
Dev and Prod.

Third party modules :
Amasty_Base
Amasty_Feed
Amasty_ProductAttachment
FireGento_FastSimpleImport
CtiDigital_Configurator
MSP_ReCaptcha
MSP_TwoFactorAuth
Magehelper_Menusearch
SchumacherFM_Mocks
Smile_DebugToolbar
Smile_ElasticsuiteAdminNotification
Smile_ElasticsuiteCore
Smile_ElasticsuiteCatalog
Smile_ElasticsuiteCatalogRule
Smile_ElasticsuiteCatalogOptimizer
Smile_ElasticsuiteAnalytics
Smile_ElasticsuiteQuickOrder
Smile_ElasticsuiteSwatches
Smile_ElasticsuiteThesaurus
Smile_ElasticsuiteVirtualCategory
Tigren_Ajaxsuite
Tigren_Ajaxcompare

Steps to reproduce

1. Create 'Catalog Product Search' optimizer with Apply to = 'Selected search terms' and select some search terms.
2. Start creating another new one optimizer (do not test on optimizer from p.1, because current optimizer is not applied in "Base Results" column)
3. Try to search for some query that is not selected as an optimizer search term in p.1.
4. Better to debug it, because it really depends on products how they will be ordered

Expected result

1. Optimizer from p.1 should not be applied, because query text is not in the list of 'Apply to' search terms. Search result in optimizer preview is the same as on the search result on the Frontend.

Actual result

1. Optimizer from p1 is applied.
2. Search result in optimizer preview differs from the search result on the Frontend.

P.S. The same with a category. If you have some optimizer A with selected categories and then in another optimizer B search for some another category in Preview, optimizer A is applied anyway.

[sevka]

P.S.
Here is the plugin I implemented for now to fix it on my project:

public function beforeCreate(
        \Smile\ElasticsuiteCatalogOptimizer\Model\Optimizer\PreviewFactory $subject,
        array $data = []
    ) {
        $queryText = $data['queryText'] ?? null;
        $category = $data['category'] ?? null;

        if ($queryText === null && $category === null) {
            return null;
        }

        if ($queryText) {
            try {
                $query = $this->queryFactory->create();
                $query->loadByQueryText($queryText);
                /*
                Even if there is no entry in search_query with such text we need to assign empty Query to search context
                so the optimizers will be properly filtered later.
                */
                $this->searchContext->setCurrentSearchQuery($query);
                // phpcs:ignore VCQP.CodeAnalysis.EmptyBlock.DetectedCatch
            } catch (LocalizedException $e) {
                // just in case, an exception should never be thrown
            }
        }

        if ($category) {
            $this->searchContext->setCurrentCategory($category);
        }

        return null;
    }

[rbayet]

Hello @androshchuk,

Could you confirm the issue and validate/integrate the proposed fix ?

[androshchuk]

Hello @sevka
Thank you for your request. I researched this and it really looks like a bug.
Would you like to design it as PR, not as a plugin?
Or let me do it

Regards

[sevka]

@androshchuk
I see you already implemented the fix. Thanks! But I found one more problem: after my fix during the optimizer creation, preview actually doesn't work. Products lists are always the same and I never see those red and green arrows. If I edit an existing list - it works fine. I'm pretty sure you can reproduce this issue as well even after your fix.
The problem is here I believe:

Do you see this first element of $functions with an empty index? This is actually the current optimizer I'm creating right now. After array_intersect_key() call we lose this element so the current new optimizer is never applied and I never see the real result of this optimizer.
Could you fix it as well, please?

[sevka]

@androshchuk
I fixed it with plugin again:

    public function afterGetOptimizerIds(
        \Smile\ElasticsuiteCatalogOptimizer\Model\Optimizer\OptimizerFilterInterface $subject,
        ?array $result
    ) {
        $result[] = '';

        return $result;
    }

[androshchuk]

Hello @sevka
Nice catch!
It seems that the problem was also when editing (changing the parameters of the optimizer).
Thank you for your contribution.

Regards

[sevka]

When editing - for me it works fine. Actually this the difference: existing optimizer already has ID and it is in the array. Try to test this case please: open some existing optimizer and change something in the optimizer configuration but do not save it. Then run a preview. Once I've got some weird result but then I was not able to reproduce it again. I see there is a some cache also, maybe this is the reason.

[androshchuk]

Hello @sevka
I meant for Request type Category Product View.
I checked again for this type and convinced that the current optimizer id need.

@rbayet please check our PR #1850