Disjunctive facets may break when used with signed search keys

[TCMiranda]

Hello! I'm having trouble to make disjunctive facets work with signed search keys.

I think it's related to this: https://github.com/elastic/search-ui/issues/347

On this line, I see that we are cleaning up request filters, but on my case filters are still sent this way:

Which seems to cause some kind of issue with AppSearch using signed search keys.

  "alerts":[{"code":5001,"message":"Degraded search results","link":"https://swiftype.com/documentation/app-search/alerts#5001"}]

What I tried:

• If I remove filters on that request it works even with a signed search key
• Also if I change the signed search key to a normal search key, it also works.

One last thing My search key only applies one filter:

Any help is much appreciated!! Thanks

[zenati]

same problem here. Removing Disjunctive facets fixes the issue for the signed key. But how to make it work with Disjunctive facets ?

[JasonStoltz]

Hey, I'm really sorry for the late response. I'm digging into this now.

[JasonStoltz]

I set up a disjunctive faceting example in codesandbox to try to reproduce.

codesandbox.io/s/signed-search-key-issue-76quc

I can't quite reproduce what you are describing.

[TCMiranda]

Hi, seems right Jason. Are you sure there aren't differences between the backend on Swifttype and Appsearch 7.6.2?

[TCMiranda]

Also, about the syntax, I've used the one with "all" inside of it.

filters: { all: { world_heritage_site: 'true' } }

Instead of

filters: { world_heritage_site: 'true' }

[calitidexvii]

We have the same issue here on App Search version 7.9.1. Using a Signed Search Key with a single filter similar to @TCMiranda's example, the API returns "Degraded search results" because the filters are overridden when retrieving facets. Using a normal search key or a Signed Search Key without filters works correctly.

As a point of interest, I replicated these conditions using the Python lib and received the same results.

[calitidexvii]

@TCMiranda, have you found a workaround? The line you mentioned in your comment above seems promising. For example, if removing appliedDisjunctiveFilter results in no filters at all then removing filters from the search.

[TCMiranda]

Sorry no workaround. We are just not using it. We created a custom search component that aways show the options we want. We loose counter though.

[calitidexvii]

@TCMiranda I think you were right. We modified that function at line 174 to test whether the length of any is 0 and if so, delete it from filters. For our use-case, this makes everything work perfectly using a Signed Search Key with embedded filters. This is not a robust or recommended solution, so YMMV, but I think it at least provides a starting point. We'll try to develop this idea further and maybe @JasonStoltz can confirm whether this is the right direction.

var disjunctiveQueriesPromises = listOfAppliedDisjunctiveFilters.map(function (appliedDisjunctiveFilter) {
  var testFilters = filters.removeFilter(appliedDisjunctiveFilter).filtersJSON;
  if(testFilters.all[0].any.length == 0) {
    delete testFilters.all[0];
  }
  return _this._performSearch(_extends({}, params, {
    filters: testFilters,
    page: _extends({}, page, {
      // Set this to 0 for performance, since disjunctive queries
      // don't need results
      size: 0
    }),
    analytics: analytics,
    facets: defineProperty({}, appliedDisjunctiveFilter, params.facets[appliedDisjunctiveFilter])
  }));
});

[calitidexvii]

The Elastic engineers found the problem. It was actually on the back-end and not a fault of the app-search-javascript lib. The fix will be released in 7.9.3. I'll confirm once I have an opportunity to test the fix.

[adnan-i]

I just tried it against 7.9.3 and it doesn't seem to be fixed yet.

[calitidexvii]

Confirmed, still receiving "Degraded search results" on 7.9.3.

The error, however, is fixed using Signed Search Keys with the Python lib, so I think there's another issue in the app-search-javascript lib.

[calitidexvii]

The issue was identified by support and a fix is planned for v7.11. Here are the details:

"Deeply nested empty filters are causing issues because they aren't caught by the filter.blank? check since they contain subfilters. This causes empty boolean queries to be sent to Elasticsearch, which returns errors.

This removes/ignores empty subfilters by recursively filtering them out in CompositeQueryFilter. It also has the side effect of normalizing nested filters by wrapping them as arrays.

The planned fix is to change the condition for overriding @all_subfilters with filter_definition because we think we only need to care about the case when it's a field name (not any/all/none). It should also prevent @all_subfilters from being reset if all of its subfilters happen to be empty."