Bug description

First of all, I apologize that it is not reproduced with sample data. Related: https://github.com/apache/superset/issues/24355

Version: 4.1.2 Installation Method: docker compose with docker-compose-non-dev.yml Chart: Pie Chart Query:

SELECT "국내/해외" AS "국내/해외", SUM(CASE WHEN 거래구분 = '투자' THEN 거래금액 ELSE 0 END) AS "투자금액" 
FROM demo."전체_거래내역_뷰" GROUP BY "국내/해외" ORDER BY "투자금액" DESC 
 LIMIT 100;

Query Results:

국내/해외   투자금액
국내  817280006121
해외  118777753521
    20596314924

Expected Result All values of "신주", "구주", and "NULL" should be displayed in the pie chart.

Actual Result Only the NULL value is displayed in the pie chart, and the data for "신주" and "구주" are not shown.

After applying Coalesce to leave only "신주" and "구주", the chart does not render at all.

Screenshot: Image Image

Another type of issue also occurred: in the following case, none of the sections were rendered. In another case, although there should be a total of 7 sections displayed in the pie chart, only 5 sections were rendered. This occurs regardless of whether "Sort by Metric" is enabled, and the same issue persists even when Row Limit is set to 50,000.

Query Results:

벤처유형            투자금액
<NULL>             466859622530
벤처캐피탈투자기업    337138509760
기술평가기업         85042661648
연구개발투자기업      38018558364
기술혁신형중소기업    24474113510
신기술개발기업       4319809998
경영혁신형중소기업    800798756

However, if you look at the rendered below, Null and the "벤처캐피탈투자기업" section are not rendered.

Screenshot: Image

Screenshots/recordings

No response

Superset version

4.1.2

Python version

3.11

Node version

18 or greater

Browser

Chrome

Additional context

No response

Checklist

  • [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
  • [ ] I have searched the GitHub issue tracker and didn't find a similar bug report.
  • [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Comment From: dosubot[bot]

Hey @jihun-ddock! I'm Dosu, your friendly bot here to help you solve bugs and answer your questions while you wait for a human maintainer. Let's tackle this issue together!

The issue you're experiencing with the pie chart in Superset, where only NULL values are displayed and other sections are omitted, might be related to how NULL values are handled in the visualization logic. In Superset, NULL values in pie charts are represented with the name <NULL>, and there was a known issue with null labels on pie charts that was addressed in a previous update [1].

Given that the problem persists even after using the COALESCE function and adjusting sorting and row limits, it might be worth checking if the issue is related to the specific version of Superset you are using (4.1.1 or 4.1.2). The changelog mentions a fix for null labels, which could be relevant to your situation.

To troubleshoot further, consider the following steps: 1. Ensure that your Superset instance is updated to the latest version, as there might be fixes for related issues. 2. Double-check the query and data to ensure that the expected categories are correctly represented and not inadvertently filtered out. 3. Review any custom configurations or settings that might affect the rendering of the pie chart.

If the issue persists, it might require a deeper investigation into the specific rendering logic of the pie chart in your Superset setup.

To continue talking to Dosu, mention @dosu.


Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

Comment From: rusackas

What DB is this querying, out of curiosity? I'm curious about the COALESCE support.

Comment From: jihun-ddock

What DB is this querying, out of curiosity? I'm curious about the COALESCE support.

@rusackas I used Postgresql.

Comment From: jihun-ddock

@rusackas I found out why it looks good in results but it's not rendered.

Image

SQL Lab ran the same query, and the result found a problem where the numeric value comes out as String. But I haven't confirmed why it comes out as String yet. Any help would be appreciated.

Comment From: suryanshpratap825

Hi @rusackas, @jihun-ddock ,

Try to extract the query and run it directly in SQL Lab—I'm referring to the chart's query. Please take a look at the images below. This will show you the exact SQL query that is hitting the database and returning the results.

Image

Image

Sometimes, row-level security (RLS) policies or additional filters are applied, which may prevent the data from appearing in the chart. Running the query separately will help you identify if that's the case.

You can also try executing the same query in SQL Lab. If you still face the same issue there, let me know. Otherwise, this process should help you understand why the data isn't showing up during chart rendering.

Comment From: jihun-ddock

@suryanshpratap825 Thank you for your reply. As mentioned in the above comment, when the same query as the query from View query is executed in SQL Lab, if the number is too large, it comes out as a value in the form of a string including "".

Image

And It occurs when Column type is numeric(18, 3) and total value is higher than 10^11. Maybe it's related in https://github.com/apache/superset/issues/30209

Finally, I solved this problem by casting all the Numeric type columns to BIGINT in the query. That way, it doesn't come out as a string(with "") and all sections are rendered well. Perhaps, in dealing with large numbers in the frontend code, it needs to be modified so that the values in the string can also come out well. First of all, I'm temporarily responding with a solution through casting, so I think I'll modify the frontend code later.

Comment From: suryanshpratap825

@jihun-ddock Thank you for the detailed explanation and the workaround! That makes sense — especially the part about large numeric(18,3) values being returned as strings due to their size. Casting to BIGINT is a smart temporary fix. I'll keep an eye on #30209 for any updates and also consider the frontend changes to better handle such cases in the future.

Comment From: rusackas

@justinpark has been doing some related work around better bigint support. I wonder if he's resolved anything here along the way or has it on his radar.