Gaps in the Time-series area chart

[AkiRyugamine]

When building a Time-series area chart, there are gaps in the graph. I'm using PostgreSQL 13. The Time Grain is set to a day, so the days are plotted on the Y-axis. In the query results, it's evident that there is data (sum of numbers) for the days where there are gaps in the chart and its not null or 0. Setting Show Empty Columns is not affected the chart and have no effect

• browser type and version: in any browser
• superset version: 2.1.0
• python version: 3.8
• node.js version: 10.19.0
• any feature flags active: none

[gl]

I have a similar issue with time series line and it seems to be related to time slots when the returned value is an integer whereas other are float. Adding 0.001 to the metric fixes the drawing by forcing all values to be float.

superset version: 2.1.0 dockerized and deployed with helm chart 0.9.1

The issue appeared with 2.1.0. It's not seen with 2.0.1 nor with legacy time series line chart in 2.1.0.

[sfirke]

Could it be related to this: #21093 ?

[gl]

It looks different. Here we are reporting that the values are not graphed in spite of these values being returned by the database correctly. It is not related to line extrapolation. And again, I can simply fix it by adding 0.001 to the metric.

I'm starting to wonder if it's not an issue with large integers somehow in one of the js libraries used to draws graphs (echarts maybe ?).

[AkiRyugamine]

I can simply fix it by adding 0.001 to the metric.

Please, tell about it more. How you could did it? I try to use CAST and ROUND functions, but Superset ignores it and still converting values into integer. But this functions work correctly from pgadmin, for example

[gl]

@AkiRyugamine

With a user-defined metric in the dataset:

[AkiRyugamine]

@gl I just tried it, but it seems that Superset continues to ignore any settings and changes related to the format of the displayed data and continues to round numbers, even if I add 0.001 to them. Maybe i should change something in settings or variables affecting this?

[AkiRyugamine]

I found temporal solution for this problem. I get SUM of needed values, round up it to integer and finally add 0.1 to them
ROUND(SUM(column_name))+0.1
Integers with more than 13 didgits not displayed on the chart graphic, but if it are float - it works. But I still need for permanent fix for this and the reason why it might be happening

[gl]

Could it be an issue with Echarts and not superset itself ? Any take on this from superset dev team ?

(btw, I second the analysis that it seems to be related to very large integers)

[gl]

It does look like the problem is javascript MAX_SAFE_INTEGER (2^53-1)

Shouldn't superset convert automatically integers to float when they're bigger than this limit ?

I opened an echarts bug as well apache/echarts#18693

[rusackas]

I'm not sure where the solution lies... is the database column an integer, or is it a float? Is this in the Chart's logic somewhere, or in core Superset's? I don't have a test case to try this out at the moment, but a PR here would be welcome if there's a clear point at which we should fix this in Superset.

[rusackas]

This is at risk of being closed as inactive, if nobody has any time to volunteer to work on it. Not that we want to close real issues, but an inactionable backlog hurts more than it helps, so we must whittle even if it pains us.