[Lens] Automatically enable show array values for non-numeric runtime fields

[dej611]

Summary

Fixes #148613

After investigating the issue via a different approach #149011 I've decided to handle it in this minimal way.
This PR will automatically switch the show_array toggle for non numeric fields avoiding as much as possible direct appearance of the error to the user.
If the user decides to explicitly disable the toggle, then the runtime error will be shown (the message there can still be improved).

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space.	Low	High	Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks.	High	Low	Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled.	Medium	High	Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: f22b93b

Metrics [docs]

Async chunks

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

id	before	after	diff
lens	1.3MB	1.3MB	+77.0B

History

• 💔 Build #100673 failed 4c9ff39

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

[drewdaemon]

Works well. I understand that this is quite an edge case so I'm not sure how much effort it's worth to polish it. That said, have you considered disabling the toggle in this case? I'm not sure why it's useful to the user to be able to turn show array values off when we know it's going to cause an error.

[stratoula]

This works fine, it seems from the documentation that top metrics doesn't work well with array values https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-top-metrics.html so it makes sense to me.
The error message is very confusing though. We can improve the UI either with a better error message or following Andrew's suggestion. I don't have a preference. With that being said, I am fine as it is now, we can always see if this confuses our users and improve.

[dej611]

That said, have you considered disabling the toggle in this case? I'm not sure why it's useful to the user to be able to turn show array values off when we know it's going to cause an error.

On one hand that would make it easier to maintain, on the other hand if user knows the runtime field is not returning an array, then they would pay a perf toll for the request.

The error message is very confusing though. We can improve the UI either with a better error message or following Andrew's suggestion. I don't have a preference. With that being said, I am fine as it is now, we can always see if this confuses our users and improve.

I agree the error message is very confusing, but fixing it properly requires quite some code to add - as for the linked closed PR - which I would delay right now.
My idea is to fix 99% of the issue with this simple PR and then take care of the remaining bits thinking carefully on how to do it right.

[stratoula]

Agree, let's merge