Signed search keys are not supported for all query types

[JoshMock]

When instantiating an AppSearchAPIConnector, you can provide a signed search key rather than the public search key. Here's an example JSON object that we're passing in a signed key for some queries:

{
  "result_fields": {
    "full_name": {"raw": {}, "snippet": {"size": 100, "fallback": true}},
    "url": {"raw": {}},
  },
  "filters": {"is_public": "true"},
}

This works as expected when running the setSearchTerm action with default options (i.e. hitting the search.json endpoint). However, when running with the autocompleteSuggestions option set to true (i.e. hitting the /query_suggestion endpoint), these requests can fail, with the following response:

[400] Options contains invalid keys: result_fields and filters

This is because the options encoded in the JWT are applied to all query requests, and autocomplete queries do not support the result_fields and filters options that regular queries do.

A few possible solutions:

• Document this as expected behavior and recommend using separate connector and driver instances when you need to support both normal and autocomplete queries
• Add an option to the connector to pass a different searchKey when performing autocomplete queries
• Add an option to setSearchTerm to pass a different searchKey on a per-query basis that overrides the key that was set when instantiating the connector

// pinging @JasonStoltz because we discussed this earlier today on Slack

[botelastic[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Is this issue still important to you? If so, please leave a comment and let us know. As always, thank you for your contributions.

[mattiloh]

What's the best workaround to use different signed keys for query suggestions and actual search queries? It seems like the only way around is implementing the search request logic from scratch, since the top-level provider is not supporting dedicated keys for suggestion and search queries. I didn't dig deep enough into the details though, since I just started evaluating Elastic App Search for our product. But any hint on good workarounds is highly appreciated 🙂

[TCMiranda]

Hey @JasonStoltz Can you update what is the status on the development of this issue? My issue with signed search keys occurs when I click to filter with facets.

Two requests are sent. The first one resolves fine, but the second one gives me that:

{
  "meta":{
    "warnings":[],
    "page":{"current":1,"total_pages":1,"total_results":0,"size":10},
    "alerts":[{"code":5001,"message":"Degraded search results","link":"https://swiftype.com/documentation/app-search/alerts#5001"}]
  },
  "results":[]
}

If I change to static keys it works fine.

[TCMiranda]

Oh, I think this is a different issue! The second request is made to get disjunctive facets, right?

But in my case, I had no filters, which caused the request to be made this way:

If I remove this empty filter property, it works.

[JasonStoltz]

@TCMiranda I've responded to your issue in elastic/app-search-javascript. Let's keep that conversation separate!

[joemcelroy]

closing this as wont fix.