[XY Chart] Mixing Time and Linear Bar series throws an internal error

[dej611]

Describe the bug When mixing two Bar series, with one Time and the other Linear X scales, leads to the charts area to crash (blank area) and an error appears in the console.

To Reproduce Steps to reproduce the behavior:

1. Create a duplicate of the 35_test_time.tsx story
2. Add the following series to it:

   <BarSeries
       id="data2"
       xScaleType={ScaleType.Linear}
       yScaleType={ScaleType.Linear}
       xAccessor={0}
       yAccessors={[1]}
       data={[
         [2400, 1],
         [500, 2],
         [700, 3],
       ]}
     />

3. Add the new story in the bars.stories.tsx
4. Start Storybook and navigate to the story page.

Expected behaviour The two scales should be independent and just split the series as it happens when mixing a Time and an Ordinal scales together (try to change the xScaleType={ScaleType.Linear} to Ordinal to see the difference).

Screenshots

Additional context

In Lens the user could configure multiple "layers", without particular constraint on types, which could lead to this situation.

Errors in browser console

Uncaught RangeError: Invalid array length
    at new ScaleContinuous (scale_continuous.ts:229)
    at Object.computeXScale (scales.ts:111)
    at getScaleForAxisSpec (axis_utils.ts:166)
    at Object.computeAxisTicksDimensions (axis_utils.ts:99)
    at compute_axis_ticks_dimensions.ts:71
    at Array.forEach (<anonymous>)
    at compute_axis_ticks_dimensions.ts:68
    at resultFuncWithRecomputations (index.js:77)
    at index.js:70
    at index.js:30

The above error occurred in the <SpecsParserComponent> component:
    in SpecsParserComponent (created by ConnectFunction)
    in ConnectFunction (created by Chart)
    in ErrorBoundary (created by Chart)
    in div (created by Chart)
    in Provider (created by Chart)
    in Chart (created by storyFn)
    in div (created by Story)
    in Story (created by storyFn)
    in storyFn
    in ErrorBoundary

React will try to recreate this component tree from scratch using the error boundary you provided, ErrorBoundary.

The above error occurred in the <SpecsParserComponent> component:
    in SpecsParserComponent (created by ConnectFunction)
    in ConnectFunction (created by Chart)
    in ErrorBoundary (created by Chart)
    in div (created by Chart)
    in Provider (created by Chart)
    in Chart (created by storyFn)
    in div (created by Story)
    in Story (created by storyFn)
    in storyFn
    in ErrorBoundary

React will try to recreate this component tree from scratch using the error boundary you provided, ErrorBoundary.

Kibana Cross Issues Add any Kibana Lens issue related issues here.

Checklist

• [x] every related Kibana issue is listed under Kibana Cross Issues list
• [x] kibana cross issue tag is associated to the issue if any kibana cross issue is present

[markov00]

Time and Linear can be mixed together, but there are some limitation that needs to be considered:

• We have an internal logic that gracefully fallback mixed scale types as you are using: basically when using Time + Linear everything will fallback to linear, when using Time or Linear + Ordinal, everything will fall back to Ordinal
• When fallback to linear but you are using Bars, we try to compute internally the width of a bar from the data domain we got. The width we try to compute, if not specified, is the minimum value between sorted consecutive values in the x domain. In your case you are mixing values that are on two very very different distances, one of the orders of few thousands and the other of order thousand billion. The logic tries to find a bar width that can be nicely represented into this very wide spectrum. Unfortunately, we have another piece of code that computes ticks for that spectrum and that initializes an array of the number of expected ticks in this case that exceed the max value of 2^32 number of slots for instantiating an array (that's why the RangeError: Invalid array length error)

We should fix the part of the code to compute the number of ticks to avoid such a use case. This was anyway something that we want to change/clean up in the near future, cleaning all the scale functions we have