Dashboard/Chart/Dataset export endpoints inherit 1-year Cache-Control, causing stale/cached exports

[pandvan]

Bug description

/api/v1/dashboard/export/ and sibling export endpoints for charts/datasets/) return:

Cache-Control: public, max-age=31536000
Expires: <+1 year>

because Flask's send_file() falls back to app.config['SEND_FILE_MAX_AGE_DEFAULT'] when the call site doesn't pass max_age. That default, in superset/config.py:

# Cache static resources.
SEND_FILE_MAX_AGE_DEFAULT = int(timedelta(days=365).total_seconds())

should be meant for hashed static assets (JS/CSS/images), but none of the export endpoints override it, so every dynamic zip export inherits a public 1-year cache lifetime.

Steps to reproduce

1. Dashboard List → bulk-select one or more dashboards → Export.
2. Immediately export the identical dashboard set again (same ids → identical ?q= query string).
3. In Chrome: the 2nd request is served (from disk cache) — 0 bytes transferred, ~0ms wait. If the underlying dashboards changed between step 1 and step 2, the downloaded zip is silently stale (identical bytes to the first export).

Expected results

Every export request is regenerated server-side and never served from browser cache, regardless of whether the query string repeats.

Actual results

The browser reuses the previous response for an identical query string, because the server explicitly marks the response public, max-age=31536000.

Suggested fix

Pass max_age=0 explicitly in the send_file() calls used by export endpoints (superset/dashboards/api.py::export, and the equivalent methods in the chart/dataset APIs), instead of inheriting the global static-asset default.

Screenshots/recordings

No response

Superset version

6.1.0

Python version

3.11

Node version

Not applicable

Browser

Chrome

Additional context

Additional context

• Regression trigger: fix(export): replace iframe with fetch to avoid CSP frame-src violations #35584 (fix(export): replace iframe with fetch to avoid CSP frame-src violations)
• Related, does not fix this: [Config] Cache static resources #8370 ([Config] Cache static resources) — introduced DEFAULT_HTTP_HEADERS/OVERRIDE_HTTP_HEADERS
• Verified via HAR comparison of repeat export requests in Chrome vs Firefox

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]

Hi @pandvan! I'm Dosu and I'm helping the Apache Superset team.

Your analysis is spot-on. I confirmed that all three export endpoints (dashboards, charts, datasets) call send_file() without passing a max_age parameter, so they all inherit the global 1-year cache lifetime:

• Dashboard export — send_file(buf, mimetype="application/zip", as_attachment=True, download_name=filename) [1]
• Chart export — identical pattern [2]
• Dataset export — identical pattern [3]

And the global default that applies [4]:

SEND_FILE_MAX_AGE_DEFAULT = int(timedelta(days=365).total_seconds())

None of these endpoints set any cache-control headers after the send_file() call either — the only post-response manipulation is setting a tracking cookie for download completion.

Your suggested fix of passing max_age=0 to send_file() in each of these three call sites is the minimal and correct approach. Alternatively, the response headers could be set explicitly after send_file():

response = send_file(buf, mimetype="application/zip", as_attachment=True, download_name=filename)
response.cache_control.no_store = True

Either way, it's a straightforward three-file change.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[hainenber]

Thanks for reporting this, @pandvan! There are a few other export endpoints that would reap similar benefits with max_age=0 as well. PR in progress