[Lens] Pass used histogram interval to chart

[flash1293]

Closes #85924

We previously fixed a similar but for date histograms. In order to draw bars of the correct with, the visualization has to know the underlying interval. elastic-charts tries to infer it from the data (e.g. if one data point starts at 20 and the next at 30, it assumes an interval of 10), but this strategy doesn't work for sparse data. This PR makes it explicit by storing the used interval in the serialized agg config and providing a helper to read the interval from the column.

To test, go to Lens with logs sample data and configure a "bytes" histogram with count of records, then pick a small time range (e.g. 30mins). There will only be a few data points, so the chart can't infer the interval from the data.

This PR:

master:

This will allow us to fix this bug #91481 as well because this way we can pass the information about the actually used interval to the filter building logic.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[wylieconlon]

Tested and this works as expected!

[wylieconlon]

This logic is duplicated with the write and serialize functions. I can't think of a better way, but maybe you can?

[ppisljar]

this seems very different to how we handle this for date_histogram:
we don't put this is serialized agg config, but rather just on the datatable column meta information. We also use its own property to store that, instead of merging it into existing property.

could we do the same thing we do for date_histogram for histgram as well ? or change how we do date_histogram ?

in either case i would prefer to have a separate property for storing this, which can also be achieved using the aggconfigs serialization.

[ppisljar]

we could create a new property on this aggConfig calculatedInterval and make its serialize method:

      serialize: (val, aggConfig) => {
          const autoBounds = aggConfig?.getAutoBounds();
          if (aggConfig && autoBounds && aggConfig.params.interval === autoInterval ) {
            const usedInterval = calculateHistogramInterval({
              values: autoBounds,
              interval: aggConfig.params.interval,
              maxBucketsUiSettings: getConfig(UI_SETTINGS.HISTOGRAM_MAX_BARS),
              maxBucketsUserInput: aggConfig.params.maxBars,
              intervalBase: aggConfig.params.intervalBase,
              esTypes: aggConfig.params.field?.spec?.esTypes || [],
            });
            return usedInterval;
         }
         return aggConfig.params.interval;
       }

we don't need any deserialize method for it, write should be _.noop

[flash1293]

@ppisljar The difference to date histogram is that the real interval is only known during data fetching (for date histogram we can derive it statically based on the current time range, but for histogram auto interval we need the extra request to fetch min and max). I really like your idea of introducing a hidden "param" which is just used for serialization, that's a much cleaner implementation. I will change the implementation on this PR.

[ppisljar]

but we could do date_histogram in the same way as well right, thus eliminate the need of tabify having special knowledge about it ?

[flash1293]

@ppisljar Yes, that's a good point. I can do the refactoring for this on this PR as well.

[flash1293]

@ppisljar I refactored the number histogram interval as discussed, could you take a look? I tried to do the date histogram in the same way, but it's a little bigger in scope than I thought, I will create a separate tech debt issue for this.

[ppisljar]

code LGTM

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 35ebddc

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
data	704	705	+1

Async chunks

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

id	before	after	diff
lens	907.9KB	908.1KB	+198.0B

Page load bundle

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

id	before	after	diff
data	912.1KB	913.9KB	+1.8KB

History

• 💔 Build #107663 failed dd5025a
• 💔 Build #107649 failed 32250aa
• 💚 Build #106764 succeeded 812ef89
• 💔 Build #106568 failed b75a99c
• 💔 Build #106521 failed d4837cf

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