Front End Potentially Makes Bad Requests to Back End: Too Many Time Steps

[lepeuvedic-natixar]

Problem: The back-end is specified to reject request that require more than 10000 time steps. This is significantly more than can be displayed with clarity on large high-res screens (imagine a bar chart with 10000 bars). The current front-end has no guard against requesting more than 10000 time steps, other than being locked on always requesting monthly data (and of course it's unlikely any client will have 10000 months of data any time soon).

Steps to Reproduce: The problem will show up as soon as the incorrect request issue #37 is corrected.

1. Log in and enter Dashboard
2. In the data range picker select 24 months (24 months represent 17520 hours if there is no February 29th in the range)
3. Click "Hour" on any of the charts
4. Observe: unpredictable incorrect behavior as the front-end processes a 4xx answer from the back-end.

Desired Behavior: The number of time steps results from the start date, end date and the current time step(s). More than one time step can be current if the two charts, on the Dashboard, that allow the selection of the time step, are not on the same setting.

The front-end should cache data for any time step the user has already requested and received in the front-end.

The change of any of the three inputs, start date, end date and current time step, must be guarded in the following way:

• Precompute the earliest "start date" that will not generate more than MAX = 10000 time steps, given the smallest time step currently in use on the two charts, and not allow the selection of any earlier "start date".
• Precompute the latest "end date" that will not generate more than MAX = 10000 time steps, given the smallest time step currently in use on the two charts, and not allow the selection of any later "end date"
• Update the "earliest start date" computation whenever the "end date" or the smallest time step is changed, and the "latest end date" computation whenever the "start date" or the smallest time step is changed.
• Note that a complex behavior of the time step selection buttons is also required. At any time, the selection of a "small" time step, which would put an excessive workload on the servers (hourly data over a 2 year range) and would be slow to process in the front end should be rejected (button inactive with a clear explanation in the hover bubble, like "This small time step would request an excessive amount of data given the current date range".

With all three guards in place, the back-end should never need to reject the front-end request on the basis of too many steps, and it should not be too puzzling for the user either, when a small time step button suddenly becomes inactive.

[ChrisNatixar]

Scale is hard-coded to a minute in the api request. This task needs to be split into two sections: implement the correct scale for the api request, then implement error checking to ensure the required number of points are not exceeded.