fix(date-parser): reject malformed time ranges instead of scanning everything

[mikebridge]

SUMMARY

Reject malformed explicit time ranges with the existing validation error (HTTP 400 for chart-data requests), instead of silently turning them into an upper-bound-only query. MCP delegates shorthand validation to the shared parser. Valid shorthands, explicit open-ended ranges, No filter, and omitted ranges with legacy since/until bounds retain their behavior.

UPDATING.md explains the compatibility change: saved charts, filters, imports, or API requests with malformed or empty ranges must use a supported shorthand, an exact <start> : <end> range, or No filter.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Not applicable; backend validation change.

TESTING INSTRUCTIONS

1. Send a chart-data request using a valid datasource with time_range set to 2025-03-15 - 2025-04-01, 2025-03-15:, lowercase last week, an empty string, : 2025-04-01, or garbage. Verify HTTP 400 before query execution.
2. Verify 2025-03-15 : 2025-04-01, 2025-03-15 : , : 2025-04-01, Last week, and No filter retain their documented behavior.
3. Run the date-parser, MCP time-range validation, and chart-data time-range validation unit tests.

Local validation: 141 focused tests passed; 220 caller tests passed with one skip; changed-file hooks passed. The full unit suite reported 22,417 passed, 40 skipped, 2 xfailed, and three known local failures in untouched files (two ARM long-double cases and a translation fixture whose PATH omits Python).

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration
• Introduces new feature or API
• Removes existing feature or API

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for superset-docs-preview ready!

Name	Link
🔨 Latest commit	49dafa7
🔍 Latest deploy log	https://app.netlify.com/projects/superset-docs-preview/deploys/6ac9179656e40b0008dd0b82
😎 Deploy Preview	https://deploy-preview-45098--superset-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.80%. Comparing base (1b35374) to head (49dafa7).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #45098   +/-   ##
=======================================
  Coverage   82.80%   82.80%           
=======================================
  Files        3016     3016           
  Lines      192521   192525    +4     
  Branches    44842    44844    +2     
=======================================
+ Hits       159409   159418    +9     
+ Misses      30079    30074    -5     
  Partials     3033     3033           

Flag	Coverage Δ
hive	35.39% <18.18%> (-0.01%)	⬇️
mysql	53.78% <18.18%> (-0.01%)	⬇️
postgres	53.79% <18.18%> (+<0.01%)	⬆️
presto	37.17% <18.18%> (-0.01%)	⬇️
python	86.47% <100.00%> (+<0.01%)	⬆️
sqlite	53.53% <18.18%> (-0.01%)	⬇️
unit	80.08% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mikebridge]

@aminghadersohi @rebenitez1802 ready for review: a malformed time_range (no ' : ' separator and not a recognised shorthand) now fails with a clear 400 listing the accepted forms, instead of silently scanning everything before today. UPDATING.md notes the change for saved charts with a bad stored range.

[codeant-ai-for-open-source]

CodeAnt PR Risk: Low Risk

• The PR appears safe to merge; malformed explicit time ranges now fail instead of silently producing an unbounded scan.
• Tests cover chart-data 400 responses, blank temporal filters, valid ranges, and legacy bounds when time_range is omitted.

Assessed commit: 49dafa729050

[fitzee]

Verdict: approve. Nothing blocking. A few non-blocking follow-ups below.

Reviewed head b834f52be7 (base 34b3d65cc2). CI is green: 95 passed, 16 skipped, 3 neutral, 0 failing.

Regression check (run on both base and PR heads, time frozen at 2026-10-08 15:30)

I called get_since_until on 60+ inputs on both heads and diffed the results.

• Unchanged on both heads: None · No filter · Last day/week/month/quarter/year · Last 7 days · Last 24 hours · Last 5 minutes · Last 2 weeks · Next 3 months · Next week · previous calendar week/month/quarter/year · Current day/week/month/quarter/year · first week of this year · first month of this quarter · Last Monday · Last year to date · ISO and ISO-T ranges · 2024-01-01 : · : 2024-02-01 · : · 7 days ago : now · 1 year ago : today · today : tomorrow · now : now · DATEADD(...) : today · DATETRUNC(...) : DATEADD(...) · start of this month : end of this month · first of this month : today · last 2 weeks : this week · Last day : Next day · Last week · Last week · Last 7 days · time_shift with Last week and with None · legacy since/until with time_range=None.
• Now raise TimeRangeParseFailError; previously returned (None, today): "" · " " · 2024-01-01 · 7 days ago · today · now · last week · 2024-01-01 - 2024-02-01 · 2024-01-01:2024-02-01 · garbage · " Last week" · inherit · 1 year ago. Also time_range="" combined with since/until, or with time_shift.

Every valid frontend-produced form still parses. The only newly rejected inputs are separator-less strings that the parser does not recognise, plus "".

Where "" could come from:

• The frontend never sends it. buildQueryObject.ts:108 sends time_range || undefined, and has done so since 2021.
• jinja_context.py:785 and tasks/native_filter_cache.py:156 already map it to No filter.

How the new exception surfaces:

• TimeRangeParseFailError was already raised for malformed a : b input, so every caller already handles it the same way as before.
• Chart data POST and GET /chart/<pk>/data catch it at charts/data/api.py:229 and :327 and return a 400. Reports, thumbnails and cache warmup go through these endpoints.
• The unit suites for common, jinja_context, semantic_layers, charts, models, migrations/viz and mcp_service/{dataset,chart} fail on exactly the same tests on base and on the PR head, so no new failures. The pre-existing failures come from my local environment.

Non-blocking

1. Upgrade blast radius has no way to find affected charts. Any saved chart, report or alert whose stored range is separator-less and unrecognised now fails:

   • chart data returns a 400;
   • scheduled reports go to an error state;
   • thumbnails show an error.

   Before, these quietly scanned everything up to today. That is the point of the PR and UPDATING.md covers it. Operators still have no way to find the affected charts before upgrading. A sample query in UPDATING.md would help, matching slices.params / query_context where a time_range or TEMPORAL_RANGE comparator has no " : " and is not No filter, Last …, Next …, previous calendar …, Current … or first ….

2. MCP: an empty TEMPORAL_RANGE filter val now reaches the parser and comes back as "Unexpected error".

   • mcp_service/common/time_range_validation.py:116-120 returns "" unchanged. Its comment says "" is a sentinel that get_since_until() never sees.
   • That holds for the time_range fields, but not for filter values. mcp_service/dataset/schemas.py:1149-1150 and mcp_service/semantic_layer/schemas.py:198-199 run val through the same validator. I confirmed QueryDatasetFilter(col="ds", op="TEMPORAL_RANGE", val="") validates with val == "".
   • query_dataset.py:244-246 then forwards it, and the parser now raises TimeRangeParseFailError (traced by reading the code, not run end to end).
   • That error is a marshmallow ValidationError, not a ValueError (checked: issubclass(..., ValueError) is False). So it skips the except ValueError at query_dataset.py:442. It lands in the generic except Exception at :453, which logs a full traceback and returns "Unexpected error" instead of the accepted-forms guidance.

   Suggested fix: map "" to NO_TIME_RANGE in the two filter validators, or reject it there. Update the comment either way.

3. The 400 message doesn't list accepted forms. The PR comment says the 400 lists the accepted forms. The actual body for garbage is "Request is incorrect: {'time_range': ['Cannot parse time string [garbage]']}". Only MCP gives the format guidance. Either reword the claim, or give TimeRangeParseFailError a hint for the separator-less case. For example, something like 2025-03-15 - 2025-04-01 could suggest <start> : <end>.

4. Docs are stale.

   • charts/schemas.py:1446-1465 (the OpenAPI time_range description) still says "colon separated string since : until or human readable freeform" and lists X days ago and similar. Those are now valid only as one side of a " : " range.
   • The get_since_until docstring at utils/date_parser.py:497-519 has the same ambiguity.

Out of scope (pre-existing, same on base)

• MCP validate_time_range strips its input before the separator check (time_range_validation.py:116, then :136). It therefore rejects open-ended ranges: "2025-03-15 : " and " : 2025-04-01" both raise ValueError on base and on the PR head. That contradicts the "explicit open-ended ranges retain their behavior" claim for the MCP surface. Worth a follow-up.
• No production code passes since/until to get_since_until (grepped), so the "legacy bounds when time_range is omitted" path is only exercised by tests.

[aminghadersohi]

One MCP gap inline, which fitzee also noted. Otherwise, every valid form parses the same as on master. The branch now conflicts with master in UPDATING.md.

[mikebridge]

@fitzee thanks for the compatibility checks. a408ede addresses item 2: blank TEMPORAL_RANGE filter values are now rejected in both the dataset and semantic-layer request schemas, while optional top-level empty defaults are kept. The code comments now distinguish the two cases.

You're also right about my earlier error-message claim: chart data returns a 400 with the parser error and doesn't list the accepted forms. The MCP schema errors provide that guidance. The upgrade-audit helper and the parser/OpenAPI documentation improvements stay as non-blocking follow-ups outside this fix. The existing MCP open-ended-range trimming behaviour is unchanged, and this PR doesn't claim to fix it.

Validation: the focused validator, dataset and semantic-layer suites pass. The only local failures are known environment-specific timezone and numeric tests that also fail on the parent commit.

[aminghadersohi]

Verified at a408ede: blank and whitespace TEMPORAL_RANGE filters are now rejected at request validation in query_dataset and get_table, top-level empty defaults are unchanged, and CI is green.