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?

[rbayet]

Hello @aligent-lturner,

Yes, I do agree that if an attribute is marked as being filterable in search, it should allow, well, to be used as a filter.
Now for the exact operator that would be available in GraphQL and/or the ability to provide a "match" Elasticsearch/OpenSearch request, that's another story.

Historically, on the Magento 1 version at least, I think we allowed even text fields (varchar) to be filterable in search / use for promo rules, and that would result in the same type of aggregation as for dropdown attribute, a list of options based on the un-analyzed text.
So basically, in the GraphQL sense of things, that would have been an "eq" operator, ie doing a strict comparison with the text provided.
That can be sufficient for small text fields containing a small number of expressions (something that could actually have been made as a dropdown) but that's pretty limited.

The fact that you have access to a "match" GraphQL operator is either

• an oversight on our part
• the expression of the limitation that Magento introduced in 2.4.7 where an attribute cannot be set "filterable in search" if it is not "searchable"
  • something that we have fixed just recently in 2.11.16.1
  • so if they encounter a text attribute that is indeed "filterable in search", they assume it is also searchable and offer the "match" operator when building the GraphQL schema

Long story short, we'll look into it.

PS: I guess you would need, indeed, to have access to the "match" operator on that attribute of yours ?

Regards,

[aligent-lturner]

@rbayet yes, the match operator does seem to work when I modified the code to allow it temporarily, so I think that makes the most sense.

Incidentally, something that is somewhat related - using the match_type property of the FilterMatchTypeInput type results in an exception also.