bito-code-review[bot] commented on code in PR #44148:
URL: https://github.com/apache/superset/pull/44148#discussion_r4121181373
##########
superset/mcp_service/chart/tool/update_chart_preview.py:
##########
@@ -292,7 +298,7 @@ def update_chart_preview( # noqa: C901
config,
new_form_data,
dataset,
- run_compile_check=config.chart_type in ("gauge", "treemap_v2"),
+ run_compile_check=bool(plugin and
plugin.requires_compile_check),
Review Comment:
<div>
<div id="suggestion">
<div id="issue"><b>Compile-check flag from stale plugin</b></div>
<div id="fix">
`run_compile_check` is derived from `plugin` (request `chart_type`), but
line 266 can replace `config` with `merged_config` from `merged_plugin`. When
the two diverge (e.g. gauge/treemap plugin disabled via `registry.configure`,
so `plugin` is None), the compile check `requires_compile_check` mandates is
skipped. Derive the flag from the plugin owning the final `config`.
</div>
</div>
<small><i>Code Review Run #cbbddf</i></small>
</div>
---
Should Bito avoid suggestions like this for future reviews? (<a
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
- [ ] Yes, avoid them
##########
superset/mcp_service/chart/registry.py:
##########
@@ -285,6 +305,14 @@ def is_enabled(self, chart_type: str) -> bool:
def display_name_for_viz_type(self, viz_type: str) -> str | None:
return display_name_for_viz_type(viz_type)
+ def plugin_for_viz_type(self, viz_type: str | None) -> "ChartTypePlugin |
None":
+ return plugin_for_viz_type(viz_type)
+
+ def all_plugins(self) -> list["ChartTypePlugin"]:
+ """Return every registered plugin, enabled or not, in insertion
order."""
+ _ensure_plugins_loaded()
+ return list(_REGISTRY.values())
Review Comment:
<div>
<div id="suggestion">
<div id="issue"><b>Proxy-only all_plugins breaks pattern</b></div>
<div id="fix">
`all_plugins()` is implemented only on `_RegistryProxy`, breaking the file's
established pattern where every operation is a module-level function with a
thin proxy delegate (`get`, `all_types`, `is_registered`, `is_enabled`,
`display_name_for_viz_type`, and the new `plugin_for_viz_type` all follow it).
Callers cannot `from ...registry import all_plugins` the way 10+ sites import
`plugin_for_viz_type` directly; the only consumer today is
`tests/unit_tests/mcp_service/chart/test_chart_plugin_contract.py:62` via the
proxy. Its docstring also makes it the only proxy method with one.
</div>
</div>
<small><i>Code Review Run #cbbddf</i></small>
</div>
---
Should Bito avoid suggestions like this for future reviews? (<a
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
- [ ] Yes, avoid them
##########
superset/mcp_service/chart/tool/update_chart_preview.py:
##########
@@ -245,19 +250,20 @@ def update_chart_preview( # noqa: C901
dataset_rebind=dataset_rebind,
)
- merged_gantt_config = validate_gantt_form_data(
- new_form_data,
- request.dataset_id,
- dataset_context=(
- build_dataset_context_from_orm(dataset)
- if new_form_data.get("viz_type") == "gantt_chart"
- else None
- ),
+ merged_plugin = plugin_for_viz_type(new_form_data.get("viz_type"))
+ merged_config = (
+ merged_plugin.validate_merged_form_data(
+ new_form_data,
+ request.dataset_id,
+ dataset_context=lambda:
build_dataset_context_from_orm(dataset),
+ )
+ if merged_plugin is not None
+ else None
)
Review Comment:
<div>
<div id="suggestion">
<div id="issue"><b>Merged-state validation registry-gated</b></div>
<div id="fix">
Old code called `validate_gantt_form_data` unconditionally (it self-guards
on `viz_type`). The new gate `if merged_plugin is not None` makes merged-state
validation depend on registry population: when the plugins package import
fails, `registry._ensure_plugins_loaded` swallows the error and every lookup
returns None, so merged Gantt state reaches `validate_and_compile` unvalidated.
Consider a viz-type fallback or failing loudly.
</div>
</div>
<small><i>Code Review Run #cbbddf</i></small>
</div>
---
Should Bito avoid suggestions like this for future reviews? (<a
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
- [ ] Yes, avoid them
##########
tests/unit_tests/mcp_service/chart/test_histogram_boxplot_charts.py:
##########
@@ -463,3 +463,65 @@ def
test_whisker_options_alongside_whisker_type_is_consumed(self) -> None:
}
)
assert config.whisker_type == "min_max"
+
+
[email protected](
+ ("adhoc_filters", "expected_metrics"),
+ [
+ ([], []),
+ (
+ [
+ {
+ "expressionType": "SQL",
+ "clause": "HAVING",
+ "sqlExpression": "COUNT(*) > 1",
+ }
+ ],
+ [
+ {
+ "expressionType": "SQL",
+ "sqlExpression": "COUNT(*)",
+ "label": "COUNT(*)",
+ }
+ ],
+ ),
+ ],
+)
+def test_histogram_query_matches_frontend_build_query(
+ adhoc_filters: list[dict[str, str]], expected_metrics: list[dict[str, str]]
+) -> None:
+ """Histogram queries select the binned column and apply
histogramOperator."""
+ from unittest.mock import patch
+
+ from superset.mcp_service.chart import chart_helpers
Review Comment:
<div>
<div id="suggestion">
<div id="issue"><b>Inline imports violate BITO 12745</b></div>
<div id="fix">
Hoist the inline `from unittest.mock import patch` and `from
superset.mcp_service.chart import chart_helpers` to module level like sibling
chart tests (`test_chart_plugin_contract.py`, `test_geographic_chart.py`); BITO
rule 12745 permits inline imports only for documented circular dependencies.
Prefer the string-target
`patch("superset.mcp_service.chart.chart_helpers.resolve_datasource_engine")`
used by `test_geographic_chart.py`/`test_gantt_chart.py` for consistency.
</div>
</div>
<small><i>Code Review Run #cbbddf</i></small>
</div>
---
Should Bito avoid suggestions like this for future reviews? (<a
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
- [ ] Yes, avoid them
--
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]
