-
Notifications
You must be signed in to change notification settings - Fork 16.5k
fix(mcp): use chart.query_context for get_chart_data like the API does #36937
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(mcp): use chart.query_context for get_chart_data like the API does #36937
Conversation
…add raw data option This PR fixes two issues with the MCP get_chart_data tool: 1. Missing @parse_request decorator causing "missing 1 required positional argument: 'ctx'" error when calling the tool from MCP clients 2. Charts returning only a single aggregated row instead of full data. Added `include_raw_data` option that retrieves all columns from the underlying dataset without aggregation, useful for charts like big_number. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Code Review Agent Run #047a2bActionable Suggestions - 0Additional Suggestions - 1
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
Nitpicks 🔍
|
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
CodeAnt AI finished reviewing your PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #36937 +/- ##
===========================================
+ Coverage 0 68.18% +68.18%
===========================================
Files 0 639 +639
Lines 0 47701 +47701
Branches 0 5210 +5210
===========================================
+ Hits 0 32527 +32527
- Misses 0 13893 +13893
- Partials 0 1281 +1281
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Addresses reviewer feedback: - Add MAX_ROW_LIMIT (10000) to prevent excessive memory/DB load when requesting large amounts of data - Add comprehensive unit tests for GetChartDataRequest schema including the new include_raw_data field and row limit capping logic 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Addressing Review Feedback✅ Fixed: Unbounded row fetch riskAdded ✅ Added: Unit tests for new featureAdded comprehensive unit tests in
ℹ️ Re: Backward-incompatible schema change (False Positive)The CodeAnt review flagged
The flagged lines (R1117-R1130) are far outside my diff which only modified lines 978-985 in schemas.py. |
Code Review Agent Run #87d875Actionable Suggestions - 0Additional Suggestions - 1
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
This addresses Vitor's feedback that get_chart_data was returning incorrect
data (e.g., a single aggregated value instead of all data points).
The root cause was that the code was manually constructing a query from
form_data parts (groupby, metrics), which doesn't produce the same results
as the chart visualization.
The fix now:
1. Uses chart.query_context (the saved query context) which contains all
the information needed to reproduce the chart's data exactly as shown
in the visualization - same approach as /api/v1/chart/{id}/data endpoint
2. Falls back to form_data construction only if query_context is unavailable
3. Removed include_raw_data option (was solving the wrong problem)
4. Updated tests accordingly
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
CodeAnt AI is running Incremental review Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Vitor-Avila
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a non-blocking comment
Code Review Agent Run #9e29faActionable Suggestions - 0Additional Suggestions - 1
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
Addresses Vitor's feedback: instead of defaulting to 100 rows, now uses the chart's configured row_limit from form_data. Users can still override with request.limit, and MAX_ROW_LIMIT (10000) remains as a safety cap. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Code Review Agent Run #277619Actionable Suggestions - 0Additional Suggestions - 1
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
Per review feedback, charts already have enforced row limits from global config (ROW_LIMIT, SQL_MAX_ROW), so the MCP-specific MAX_ROW_LIMIT is unnecessary. This change: - Removes MAX_ROW_LIMIT constant from get_chart_data.py - Updates schema description to remove "capped at 10000" text - Removes MAX_ROW_LIMIT tests that are no longer needed - Respects chart's configured row_limit or request.limit directly 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Uses the same pattern as viz.py for fallback row_limit:
request.limit or form_data.get("row_limit") or current_app.config["ROW_LIMIT"]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
Bito Automatic Review Skipped – PR Already Merged |
apache#36937) Co-authored-by: Claude Opus 4.5 <[email protected]>
Summary
ctxerror: Added missing@parse_request(GetChartDataRequest)decorator toget_chart_datatool, which was causing the error:missing 1 required positional argument: 'ctx'when calling from MCP clientschart.query_context(same approach as/api/v1/chart/{id}/dataendpoint) instead of manually constructing queries, which was causing temporal line charts to return a single aggregated value instead of all data pointsrow_limitfrom form_data (which respects globalROW_LIMITandSQL_MAX_ROWconfig). RemovedMAX_ROW_LIMITconstant per review feedback - charts already have enforced row limits from global config.Test Plan
Verified Fix with Temporal Line Chart
Created a temporal line chart (chart 135) with
order_datevsSUM(sales)oncleaned_sales_datadataset and compared API vs MCP responses:/api/v1/chart/135/data/get_chart_dataorder_date,SUM(sales)order_date,SUM(sales)✅2003-01-06, $12,133.252003-01-06, $12,133.25✅2005-05-31, $78,918.032005-05-31, $78,918.03✅API Response (first 5 rows):
{"order_date": 1041811200000.0, "SUM(sales)": 12133.25} {"order_date": 1042070400000.0, "SUM(sales)": 11432.34} {"order_date": 1042156800000.0, "SUM(sales)": 6864.05} {"order_date": 1043798400000.0, "SUM(sales)": 54702.0} {"order_date": 1043971200000.0, "SUM(sales)": 44621.96}MCP Response (first 5 rows):
{"order_date": "2003-01-06T00:00:00", "SUM(sales)": 12133.25} {"order_date": "2003-01-09T00:00:00", "SUM(sales)": 11432.34} {"order_date": "2003-01-10T00:00:00", "SUM(sales)": 6864.05} {"order_date": "2003-01-29T00:00:00", "SUM(sales)": 54702} {"order_date": "2003-01-31T00:00:00", "SUM(sales)": 44621.96}Result: Both return identical data - 252 temporal data points with matching values.
Tested Fallback Path (charts without saved
query_context)All charts return the correct number of data points instead of a single aggregated value.
Additional Information
Reported Issues (by @villebro)
get_chart_datawas returning:missing 1 required positional argument: 'ctx'7291) instead of all data pointsRoot Causes
@parse_requestdecorator was missing - this decorator handles FastMCP's context injectionform_dataparts instead of using the chart's savedquery_contextKey Fix
Now uses
ChartDataQueryContextSchema().load(query_context_json)- the same approach as the/api/v1/chart/{id}/dataendpoint:🤖 Generated with Claude Code