Large chart data doesn't return a helpful error message

[ethan-l-geotab]

Bug description

Theres a interesting interaction where a chart which requests a lot of data for the form_data won't display correctly on chrome. It works fine on Firefox though.

The request is about 950 mbs? I'm not sure what the cutoff limit is. I think if it's probably a browser limitation.

Screenshots/recordings

The endpoint returns 200, but the frontend displays this:

On Firefox it displays correctly:

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• 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.

[dosubot]

This behavior is likely due to browser memory or parsing limits—Chrome and Firefox handle very large JSON responses differently. Superset's backend enforces row and payload size limits via configuration (like ROW_LIMIT, SQL_MAX_ROW, and SQLLAB_PAYLOAD_MAX_MB), but by default, these may not prevent extremely large responses from reaching the browser. When a huge payload (like ~950 MB) is returned, Chrome may fail to parse or allocate memory for it, resulting in a generic "Data error: Unexpected" message, while Firefox is sometimes more tolerant with large in-memory data loads.

Superset does not implement browser-specific handling for oversized responses; the frontend simply displays error messages based on the error type it receives. If the backend detects a payload that's too large (when SQLLAB_PAYLOAD_MAX_MB is set), it returns a clear "Result size exceeds the allowed limit" error, but if not, the browser's own limitations can cause unhelpful errors instead (config reference, backend logic).

To avoid this, set reasonable limits on your queries using ROW_LIMIT and/or SQLLAB_PAYLOAD_MAX_MB in your Superset config. This will ensure the backend blocks oversized responses and returns a clear, actionable error before the browser tries to process them. For very large tables, consider enabling server-side pagination or exporting data via the new streaming CSV export, which is designed to handle large datasets efficiently without crashing the browser (CSV streaming PR).

Improving the frontend to detect and display more helpful messages when browser limits are hit (for example, catching JSON parse errors or memory allocation failures) could be a valuable enhancement. For now, server-side limits are the best way to prevent this scenario.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[rusackas]

Though I'm not sure the right way to fix this at the moment (aside from tweaking limits as the bot suggested) perhaps there's a better way to display a more useful error.

[rusackas]

It does seem that if we're using fetch for this API call, it'd be possible to start receiving the stream of data, but you could check the size and abort if it's too large before processing the data and receiving the rest of the response. Something like

const controller = new AbortController();
const response = await fetch(url, { signal: controller.signal });

const size = Number(response.headers.get("content-length"));

if (size > MAX_SIZE) {
  controller.abort(); // stops downloading the rest
  throw new Error("File too large");
}

// Safe to proceed — now read/parse body
const json = await response.json();

[ethan-l-geotab]

The "Server Pagination" on the charts page DOES seem to work tho and seems reasonable. The problem for me I guess is if the user is using pagination, it is capped at 200. For queries that are particularly expensive it reruns the query with limit + offset for every new page. I'm not sure if it's acceptable for now.

I have a branch which caps the return of data size (configurable) and just sends "up to the amount of data you tell it to". something like:

Size is in config in mb and there a feature flag to use it. I'm not sure if it's the desired approach, so I'm holding off making an MR until later

[ethan-l-geotab]

I made a draft MR instead. I'm not sure what's the best approach, sorry.

[msyavuz]

Thanks for opening a pr for this!