eschutho opened a new pull request, #44462:
URL: https://github.com/apache/superset/pull/44462
### SUMMARY
The `query_dataset` MCP tool logged a full-traceback ERROR event and
returned a
generic `UnexpectedError` to the calling client whenever a caller supplied an
explicit reversed time range (a `"<start> : <end>"` range where `start >
end`,
e.g. `"2024-01-01T00:00:00 : 2020-01-01T00:00:00"`). This is benign,
actionable
user/agent-input, not a bug — but it was being treated as an unexpected
server
error.
**Root cause**
`superset/utils/date_parser.py::get_since_until()` raises a bare
`ValueError("From date cannot be larger than to date")` when `since > until`.
`query_dataset()` reaches this parser transitively:
```
query_dataset() -> build_query_dict()/execute_tabular_query()
-> QueryContextFactory.create()
-> QueryObjectFactory.create()
-> get_since_until_from_time_range()
-> date_parser.get_since_until() # raises ValueError
```
`query_dataset()`'s exception handling had specific arms for
`OAuth2RedirectError`, `OAuth2Error`, `(CommandException,
SupersetException)`,
and `SQLAlchemyError`, but **not** `ValueError`. A reversed range therefore
fell
through to the generic `except Exception`, which calls
`logger.exception(...)`
(an ERROR-level, full-traceback log captured as a Sentry event) and returns
an
unhelpful generic `UnexpectedError` to the LLM client.
This is the same root-cause family as #43517 (which added an `except
ValueError`
arm in `ChartDataRestApi._create_query_context_from_form` to convert an
unhandled 500 into a 400), but #43517 only covered the REST
`ChartDataRestApi.data`
call path — not this separate MCP tool call path, which remained a live gap.
Note: the pydantic-level guard
`common/time_range_validation.py::validate_time_range()`
intentionally does *not* validate explicit `"<start> : <end>"` ranges — its
docstring defers any parse failure to the downstream parser as "a signal the
caller can act on". So the deferred-to-downstream `ValueError` is by design;
it
just wasn't being converted into a clean, actionable result at the MCP
boundary.
**Fix**
Add a specific `except ValueError as exc:` arm before the generic
`except Exception`, mirroring the sibling-tool pattern already used in
`dashboard/tool/update_dashboard.py` and
`dashboard/tool/apply_dashboard_filters.py`. It:
- does **not** call `logger.exception` (this is expected input validation,
not a
bug — no noisy full-traceback event)
- emits a lightweight `await ctx.error(...)`, matching the other arms' style
- returns `DatasetError.create(error=str(exc),
error_type="ValidationError")`,
surfacing the actual, actionable message to the client
### TRADEOFFS
- **Failure-mode change (intended):** previously an unhandled reversed-range
`ValueError` produced a full-traceback ERROR log plus a generic
`UnexpectedError` result. Now it produces a clean `ValidationError` result
carrying the parser's own message and no traceback log. This is the whole
point of the change — a reversed date range is benign, actionable input,
so it
should not generate error-level noise or look like a server bug to the
client.
- **Scope of the `ValueError` catch:** the arm is function-wide, covering the
whole `try` block (dataset lookup, name validation, filter/query
construction,
execution, and formatting), rather than wrapping only the
`execute_tabular_query` call. This is deliberate and consistent with how
the
sibling MCP tools (`update_dashboard`, `apply_dashboard_filters`) catch
`ValueError` function-wide. A `ValueError` raised anywhere in this block is
fundamentally a malformed-input signal, and because the message is passed
through verbatim (`str(exc)`), the client always receives the real message
rather than a misleading one — so a broad catch does not mask an unrelated
error behind a wrong label; it just classifies it as a validation problem,
which is accurate for `ValueError`. The more specific `SupersetException`,
`CommandException`, and `SQLAlchemyError` arms remain ordered before it, so
domain and database errors keep their existing, more specific handling.
### TESTING INSTRUCTIONS
Added `test_query_dataset_reversed_time_range` to
`tests/unit_tests/mcp_service/dataset/tool/test_query_dataset.py`. It calls
`query_dataset` with `time_range="2024-01-01T00:00:00 : 2020-01-01T00:00:00"`
(which passes the pydantic `validate_time_range` guard unchanged and reaches
the
real `get_since_until()`), and asserts the result is a `DatasetError` with
`error_type="ValidationError"` and a message containing
"From date cannot be larger than to date" (not a raised exception, not
`UnexpectedError`).
Commands run:
```
$ python3 -m pytest
tests/unit_tests/mcp_service/dataset/tool/test_query_dataset.py::test_query_dataset_reversed_time_range
-q
1 passed in 1.37s
$ python3 -m pytest
tests/unit_tests/mcp_service/dataset/tool/test_query_dataset.py -q
103 passed, 1 skipped in 21.27s
$ ruff check <touched files>
All checks passed!
$ ruff format --check <touched files>
2 files already formatted
```
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
