GraphQL "match" filters on custom attributes not working

[aligent-lturner]

When attempting to pass a filter on a custom text attribute for the products query, no results are returned. In development mode (without compile di, an exception is thrown).

Preconditions

Magento Version : 2.4.8

ElasticSuite Version : 2.11.15.1

Environment : Both

Third party modules : None related

Steps to reproduce

1. Create a custom text attribute, and make it filterable in search.
2. Assign different values to products for the attribute
3. Attempt to filter by the attribute - e.g.

products(
  filter: {
    my_attribute: {
      match: "some value"
    }
  }

Expected result

1. Products matching the filter value are returned

Actual result

1. In production mode, with compiled di, no results are returned
2. In developer mode, an exception is thrown:

{
  "errors": [
    {
      "message": "Internal server error",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "products"
      ],
      "extensions": {
        "debugMessage": "Missing required argument $values of Smile\\ElasticsuiteCore\\Search\\Request\\Query\\Terms."
      }
    }
  ],
  "data": {
    "products": null
  }
}

Additional Information

This appears to be the same (or very similar to) #2430
I'm not sure, but I believe that the issue is with these lines:

elasticsuite/src/module-elasticsuite-core/Search/Request/Query/Filter/QueryBuilder.php

Lines 137 to 148 in 228d3cd

	if ($condition['field'] === null || isset($condition['queryText'])) {
	$analyzer = $field->getDefaultSearchAnalyzer();
	$property = $field->getMappingProperty($analyzer);
	if ($property) {
	$condition['field'] = $property;
	if (isset($condition['queryText'])) {
	$queryType = QueryInterface::TYPE_MATCH;
	$condition['minimumShouldMatch'] = '100%';
	}
	}
	}

If getMappingProperty returns null, then the check for $condition['queryText'] never happens. It would make sense to me for that if statement to be outside of the check for $property:

        if ($condition['field'] === null || isset($condition['queryText'])) {
            $analyzer = $field->getDefaultSearchAnalyzer();
            $property = $field->getMappingProperty($analyzer);
            if ($property) {
                $condition['field'] = $property;
            }
            if (isset($condition['queryText'])) {
                $queryType = QueryInterface::TYPE_MATCH;
                $condition['minimumShouldMatch'] = '100%';
            }
        }

When I tried this locally, it seemed to work ok, but I'm not sure if there's a better way to fix the issue (e.g. something within the getMappingProperty function.

[aligent-lturner]

Note - I just attempted the same with version 2.11.16, and encountered the same issue

[rbayet]

Note - I just attempted the same with version 2.11.16, and encountered the same issue

Hello @aligent-lturner,

OK, so at least that's not a side effect of #3720

Regards,

[rbayet]

Well, it seems that it could be variation of what has been fixed #3720 .

If a text attribute is filterable but not searchable, in the Elasticsuite sense of things, it should not be able to support an Elasticsearch "match", only indeed a "terms" request.
But since it ends up in an error, there is indeed a technical issue..

Now, you could switch that custom text attribute to be searchable and reindex, this will indeed "fix" the mapping by adding what makes the getMappingProperty function returns null.

Now this can create a functional issue if what you want to do is indeed filter with a match on the attribute but not make the attribute data visible per se to the product search.

@aligent-lturner is in your case switching the attribute to be also searchable "good enough" as a stop-gap solution ?

Regards,

[aligent-lturner]

@rbayet making the attribute searchable does fix the problem, but I would still consider this a bug. If an attribute is marked as being filterable in search, then using it as a filter should work, regardless of whether it's also marked as searchable, I would've thought?