SOR.find: allow to specify per-type search fields

[pgayvallet]

Summary

Fix #130616

When we added a match_phrase_prefix clauses in #82693 to improve the results when searching with a prefix search (search term ending with *), we overlooked that match_phrase_prefix must be performed against a text field. Generating such clause against a keyword field returns an error looking like:

all shards failed: search_phase_execution_exception: [query_shard_exception] Reason: failed to create query: Can only use phrase prefix queries on text fields - not on [synthetics-monitor.name] which is of type [keyword]

The problem with that is the behavior when searching for multiple types at once, as the SOM backend it doing.

Let say, for instance, that we got two types:

{
   name: 'a',
   hidden: false,
   namespaceType: 'single',
   mappings: {
      properties: { title: { type: 'text' } },
   },
   management: {
      importableAndExportable: true,
      defaultSearchField: 'title',
   },
}

and

{
   name: 'b',
   hidden: false,
   namespaceType: 'single',
   mappings: {
      properties: { 
        title: { type: 'keyword' },
        name: { type: 'text' }
      },
   },
   management: {
      importableAndExportable: true,
      defaultSearchField: 'name',
   },
}

When filtering to both those types and searching by query from the SOM UI, the request to SOR.find created here: src/plugins/saved_objects_management/server/routes/find.ts looks like:

client.find({
  search: 'foo*',
  types: ['a', 'b'],
  searchFields: ['title', 'name'],
})

Causing match_phrase_prefix clauses to be created for all tuples:

• a.title
• a.name
• b.title
• b.name

But because b.title is indexed as keyword, the whole search fail.

This is problematic because that forces all type owners to specify fields that are registered as defaultSearchField by other types to be registered as text and not keyword. Such side effect makes no sense and should be avoided.

We already encountered at least 4 times in the past few months issues because teams added new SO types with fields indexed as keyword that were already defined by existing SO types as their defaultSearchField.

This PR fixes this by allowing to specify per-type searchFields when calling SOC.find.

The previous API call now looks like:

client.find({
  search: 'foo*',
  types: ['a', 'b'],
  searchFields: {
     a: ['title'],
     b: ['name'],
   },
})

Causing match_phrase_prefix clauses to now only be created for:

• a.title
• b.name

Note: Because this PR intent is to fix the bug causing the SOM requests to fail because of the described issue, the PR only uses these per-type fields for the match_phrase_prefix clauses of the ES request. The simple_query_string part is still using all fields. The reason is simply that doing so would have caused way more changes in the search_dsl logic, without much upsides.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: ff34269
• Interpreting CI Failures
• Storybooks Preview

Failed CI Steps

• Jest Integration Tests
• Checks

Metrics [docs]

✅ unchanged

History

• 💔 Build #9216 failed edf8719
• 💔 Build #9213 failed cc42a3c
• 💔 Build #9045 failed d0bdaa2
• 💔 Build #9034 failed bc29dd5

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[pgayvallet]

Old and abandoned - closing.