KIBANA-150302 fixed displaying sampling rate of N/A if there are no t…

[ArchitGajjar]

Summary

Currently, the Storage Explorer displays a sampling rate of 0% if there are no transactions. This is misleading, as we can't actually infer what the sampling rate would be if there were transactions (which might not exist or might be dropped for whatever reason). We should instead display N/A.

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
• Flaky Test Runner was used on any tests changed
• 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

[cla-checker-service]

❌ Author of the following commits did not sign a Contributor Agreement:
1166cfa

Please, read and sign the above mentioned agreement if you want to contribute to this project

[smith]

I think it might be better to return null here. "N/A" is a presentational and locale-specific. It might be slightly more code if we returned null here and made the UI display "N/A" or the appropriate string.

Let me know if I can help in any way with getting this done.

[smith]

cc @miltonhultgren do we have anything in our API guidelines about handling 0 vs. null/undefined?

[miltonhultgren]

I agree that the API should not return a (localized) string in this situation (based on the API guidelines to separate API from UI presentation), and if this is meant to express a lack of a value then I would return a null/undefined (but this part is not stated in the guidelines).

This is for the reason that 0 may be a valid value in some cases, so it's risky to make 0 === N/A, while null is usually the standard invalid value.