aminghadersohi commented on code in PR #42196:
URL: https://github.com/apache/superset/pull/42196#discussion_r3627315762
##########
superset/views/utils.py:
##########
@@ -214,6 +215,24 @@ def loads_request_json(request_json_data: str) ->
dict[Any, Any]:
return parsed if isinstance(parsed, dict) else {}
+def get_request_json_body() -> dict[Any, Any]:
+ """Parse the request body as JSON, coercing failures to ``{}``.
+
+ ``request.is_json`` only inspects the Content-Type header, not whether the
+ body is actually parseable JSON. Callers reaching ``get_form_data`` from a
+ non-HTTP-chart-data context (e.g. an MCP tool call rendering
+ ``filter_values()``) can have a request context whose Content-Type claims
+ JSON but whose body isn't a JSON chart-data payload, which makes Werkzeug
+ raise ``BadRequest`` from ``request.get_json()``.
+ """
+ if not request.is_json:
+ return {}
+ try:
+ return request.get_json(cache=True)
+ except BadRequest:
+ return {}
Review Comment:
Confirmed — good catch. `request.get_json(cache=True)` can return a
well-formed but non-dict JSON value (`null`, a scalar, or an array), which
`get_form_data()` then treats as a mapping. Fixed in the latest push:
`get_request_json_body()` now returns `{}` unless the parsed body is actually a
`dict`, and I added a regression test
(`test_get_form_data_handles_non_dict_json_body`) covering a scalar JSON body.
Also rebased onto current `master` to resolve the merge conflict from #42126
removing `JS_CONTROL_FORM_DATA_KEYS`. See commit 7a1083e.
--
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]
