[maps] display incomplete results warning in layer legend

[nreese]

Closes #170653
Closes #170654

PR updates Maps to display incomplete result warnings in layer legend (instead of displaying toast)

Test setup

1. In console, run:

   PUT geo1
   {}
   
   PUT geo1/_mapping
   {
     "properties": {
       "location": {
         "type": "geo_point"
       }
     }
   }
   
   PUT geo1/_doc/1
   {
     "location": "25,25"
   }
   
   PUT geo2
   {}
   
   PUT geo2/_mapping
   {
     "properties": {
       "location": {
         "type": "geo_point"
       }
     }
   }
   
   PUT geo2/_doc/1
   {
     "location": "35,35"
   }
   

2. Create geo* data view

Test vector tile request warning

"View details" button for vector tile requests is out of scope for this PR. Vector tile requests use _mvt API instead of _search API. As such, vector tile requests do not use search source or request inspector.

1. create new map, add documents layer from geo* data view.
2. add filter

   {
     "error_query": {
       "indices": [
         {
           "error_type": "exception",
           "message": "local shard failure message 123",
           "name": "geo2"
         }
       ]
     }
   }
   

   

Test geojson incomplete results warning with single request

1. create new map, add documents layer from geo* data view.
2. Set scaling to "Limit results to 10000"
3. add filter

   {
     "error_query": {
       "indices": [
         {
           "error_type": "exception",
           "message": "local shard failure message 123",
           "name": "geo2"
         }
       ]
     }
   }
   

   

Test geojson incomplete results warning with multiple requests

1. create new map, add documents layer from geo* data view.
2. Set scaling to "Show clusters when results exceed 10000"
3. add filter

   {
     "error_query": {
       "indices": [
         {
           "error_type": "exception",
           "message": "local shard failure message 123",
           "name": "geo2"
         }
       ]
     }
   }
   

   

[nreese]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: c3842d9

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
maps	1066	1093	+27

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/search-response-warnings	12	18	+6

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
discover	590.3KB	590.3KB	+4.0B
maps	2.9MB	2.9MB	-19.1KB
visualizations	268.0KB	268.1KB	+4.0B
total			-19.1KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
maps	29	28	-1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
maps	46.7KB	46.7KB	+63.0B

Unknown metric groups

API count

id	before	after	diff
@kbn/search-response-warnings	14	20	+6

History

• 💔 Build #176003 failed 15339a6
• 💔 Build #175890 failed 9ebd0d4
• 💔 Build #175879 failed cc12f24
• 💔 Build #175845 failed d6ce12e
• 💔 Build #175526 failed 650efcd

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

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[jughosta]

New exports from kbn-search-response-warnings/index.ts LGTM

[nickpeihl]

I left a question, but nothing that necessarily needs to block merging.

lgtm! code review and tested errors and warnings on different layer types and settings.

[nickpeihl]

I'm slightly concerned that we may be removing useful context for the user when removing the requestDescription. Did you find the requestDescription was not helpful or inaccurate or maybe some other reason?

[nreese]

I found requestDescription to be dive too deeply into implementation details. The user only cares about what is getting loaded, like layer features or join metrics. Details about how layer features are elasticsearch aggregation buckets vs elasticsearch documents is not important and should not be surfaced at a high level. Users can interrogate the request if they really want all the implementation details.