aminghadersohi commented on code in PR #42244:
URL: https://github.com/apache/superset/pull/42244#discussion_r3616623019
##########
superset/mcp_service/middleware.py:
##########
@@ -1331,6 +1333,141 @@ def _try_truncate_info_response(
return truncated
+ def _try_truncate_data_query_response(
+ self,
+ tool_name: str,
+ response: Any,
+ estimated_tokens: int,
+ ) -> Any | None:
+ """Attempt to truncate a data-query tool response by dropping tail
rows.
+
+ Returns the truncated response if successful, None otherwise.
+ """
+ extracted = self._extract_payload_from_tool_result(response)
+ truncation_target = extracted if extracted is not None else response
+
+ try:
+ truncated, was_truncated, notes = truncate_query_result(
+ truncation_target, self.token_limit, tool_name=tool_name
+ )
+ except Exception as trunc_error: # noqa: BLE001
+ logger.warning(
+ "Query result truncation failed for %s due to %s: %s",
+ tool_name,
+ type(trunc_error).__name__,
+ trunc_error,
+ )
+ return None
+
+ if not was_truncated:
+ return None
+
+ # Mirror the info-tool path: if truncation couldn't bring the
+ # response back under the limit (e.g. a single row/scalar field
+ # alone exceeds it), fall back to the hard size-limit error instead
+ # of shipping an over-budget response.
+ truncated_tokens = estimate_response_tokens(truncated)
+ if truncated_tokens > self.token_limit:
+ return None
+
+ logger.warning(
+ "Query result for %s truncated from ~%d to ~%d tokens (limit: %d).
%s",
+ tool_name,
+ estimated_tokens,
+ truncated_tokens,
+ self.token_limit,
+ "; ".join(notes),
+ )
+
+ try:
+ user_id = get_user_id()
+ event_logger.log(
+ user_id=user_id,
+ action="mcp_response_truncated",
+ curated_payload={
+ "tool": tool_name,
+ "original_tokens": estimated_tokens,
+ "truncated_tokens": truncated_tokens,
+ "token_limit": self.token_limit,
+ "truncation_notes": notes,
+ },
+ )
+ except Exception as log_error: # noqa: BLE001
+ logger.warning("Failed to log truncation event: %s", log_error)
+
+ if extracted is not None and isinstance(truncated, dict):
+ return self._rewrap_as_tool_result(truncated, response)
+
Review Comment:
Confirmed — this was a real bug, not just a theoretical edge case.
`estimate_response_tokens` is called on the unwrapped payload dict, but
`ToolResult` (the object actually returned) adds envelope overhead — the
`content`/`type`/`text`/`meta` wrapper plus JSON-escaping of the embedded
payload string — that isn't reflected in that check. Measured empirically: for
a 20k-token payload the wrapped object came out ~440 tokens larger (~2.2%), and
the overhead is proportionally worse for small payloads (~40 tokens fixed
baseline).
Fixed in ea1e5e3 (`superset/mcp_service/middleware.py`,
`superset/mcp_service/utils/token_utils.py`):
1. In both `_try_truncate_info_response` and
`_try_truncate_data_query_response`, the size limit is now re-checked against
the final re-wrapped `ToolResult`, not the bare payload.
2. More importantly, the underlying binary search that decides *how many
rows to keep* (`_bisect_row_limit`, `_bisect_csv_row_limit`, and the phase
checks in `truncate_oversized_response`) now accepts an optional `size_fn`
callable. The middleware passes a `size_fn` that re-wraps each candidate into a
`ToolResult` before measuring it, so the search itself converges on a row count
that still fits *after* re-wrapping, instead of just re-validating the wrong
measurement afterward and giving up (hard-blocking) if it doesn't fit.
Added a regression test (`test_data_query_truncation_fits_after_rewrap` in
`tests/unit_tests/mcp_service/test_middleware.py`) that asserts
`estimate_response_tokens(result) <= token_limit` on the actual object returned
from `on_call_tool` — this fails on the pre-fix code (proportional wrapper
overhead pushes ~461 unwrapped tokens to >500 wrapped) and passes now.
All 157 mcp_service/middleware + token_utils tests pass, plus the full
mcp_service suite (3089/3090, the one pre-existing failure is an unrelated
e2e/auth test that fails identically on main).
##########
superset/mcp_service/middleware.py:
##########
@@ -1331,6 +1333,141 @@ def _try_truncate_info_response(
return truncated
+ def _try_truncate_data_query_response(
+ self,
+ tool_name: str,
+ response: Any,
+ estimated_tokens: int,
+ ) -> Any | None:
+ """Attempt to truncate a data-query tool response by dropping tail
rows.
+
+ Returns the truncated response if successful, None otherwise.
+ """
+ extracted = self._extract_payload_from_tool_result(response)
+ truncation_target = extracted if extracted is not None else response
+
+ try:
+ truncated, was_truncated, notes = truncate_query_result(
+ truncation_target, self.token_limit, tool_name=tool_name
+ )
+ except Exception as trunc_error: # noqa: BLE001
+ logger.warning(
+ "Query result truncation failed for %s due to %s: %s",
+ tool_name,
+ type(trunc_error).__name__,
+ trunc_error,
+ )
+ return None
+
+ if not was_truncated:
+ return None
+
+ # Mirror the info-tool path: if truncation couldn't bring the
+ # response back under the limit (e.g. a single row/scalar field
+ # alone exceeds it), fall back to the hard size-limit error instead
+ # of shipping an over-budget response.
+ truncated_tokens = estimate_response_tokens(truncated)
+ if truncated_tokens > self.token_limit:
+ return None
+
+ logger.warning(
+ "Query result for %s truncated from ~%d to ~%d tokens (limit: %d).
%s",
+ tool_name,
+ estimated_tokens,
+ truncated_tokens,
+ self.token_limit,
+ "; ".join(notes),
+ )
+
+ try:
+ user_id = get_user_id()
+ event_logger.log(
+ user_id=user_id,
+ action="mcp_response_truncated",
+ curated_payload={
+ "tool": tool_name,
+ "original_tokens": estimated_tokens,
+ "truncated_tokens": truncated_tokens,
+ "token_limit": self.token_limit,
+ "truncation_notes": notes,
+ },
+ )
+ except Exception as log_error: # noqa: BLE001
+ logger.warning("Failed to log truncation event: %s", log_error)
+
+ if extracted is not None and isinstance(truncated, dict):
+ return self._rewrap_as_tool_result(truncated, response)
+
Review Comment:
Confirmed — this was a real bug, not just a theoretical edge case.
`estimate_response_tokens` is called on the unwrapped payload dict, but
`ToolResult` (the object actually returned) adds envelope overhead — the
`content`/`type`/`text`/`meta` wrapper plus JSON-escaping of the embedded
payload string — that isn't reflected in that check. Measured empirically: for
a 20k-token payload the wrapped object came out ~440 tokens larger (~2.2%), and
the overhead is proportionally worse for small payloads (~40 tokens fixed
baseline).
Fix (pushed shortly) in `superset/mcp_service/middleware.py` and
`superset/mcp_service/utils/token_utils.py`:
1. In both `_try_truncate_info_response` and
`_try_truncate_data_query_response`, the size limit is now re-checked against
the final re-wrapped `ToolResult`, not the bare payload.
2. More importantly, the underlying binary search that decides *how many
rows to keep* (`_bisect_row_limit`, `_bisect_csv_row_limit`, and the phase
checks in `truncate_oversized_response`) now accepts an optional `size_fn`
callable. The middleware passes a `size_fn` that re-wraps each candidate into a
`ToolResult` before measuring it, so the search itself converges on a row count
that still fits *after* re-wrapping, instead of just re-validating the wrong
measurement afterward and giving up (hard-blocking) if it doesn't fit.
Added a regression test (`test_data_query_truncation_fits_after_rewrap` in
`tests/unit_tests/mcp_service/test_middleware.py`) that asserts
`estimate_response_tokens(result) <= token_limit` on the actual object returned
from `on_call_tool` — this fails on the pre-fix code (proportional wrapper
overhead pushes ~461 unwrapped tokens to >500 wrapped) and passes now.
All 157 mcp_service/middleware + token_utils tests pass, plus the full
mcp_service suite (3089/3090, the one pre-existing failure is an unrelated
e2e/auth test that fails identically on main).
--
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]
