Repository navigation
Conversation
…red option A chart's stored query_context can hold a post-processing operation whose options no longer satisfy the operation's signature, e.g. a `cum` step with only `operator` and no `columns`. exec_post_processing called `func(df, **options)` directly, so the resulting bare TypeError escaped as a server error even though the cause is a malformed request. Bind the resolved options against the operation's signature before calling it and raise InvalidPostProcessingError naming the operation and the offending/missing option. Only the bind is guarded, so a TypeError raised from inside an operation still propagates unchanged. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Closing: on current master |
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #45573 +/- ##
===========================================
- Coverage 84.06% 65.50% -18.57%
===========================================
Files 3056 3056
Lines 201028 201136 +108
Branches 47025 47036 +11
===========================================
- Hits 168990 131749 -37241
- Misses 28799 66432 +37633
+ Partials 3239 2955 -284
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
SUMMARY
Root cause. A chart's stored
query_contextcan contain a post-processing step whose options don't satisfy the operation's signature, e.g.{operation: 'cum', options: {operator: 'sum'}}with nocolumns.QueryObject.exec_post_processingcalledfunc(df, **options)directly, so the failure surfaced as a bareTypeError: cum() missing 1 required positional argument: 'columns'rather than a validation error.Fix. After options are resolved (so
resample'sfill_time_rangeflow is unchanged), bind them againstinspect.signature(func)and raiseInvalidPostProcessingErrornaming the operation and the missing/invalid option. Only thebindis guarded; the operation call itself is not wrapped, so a genuineTypeErrorfrom inside an operation still propagates. Operations with**kwargsand ops registered viaEXTRA_PANDAS_POSTPROCESSING_OPSbind naturally; callables without an introspectable signature skip the pre-check.Tradeoffs.
TypeError(potentially a 500) becomesInvalidPostProcessingError(4xx, via the existingQueryObjectValidationErrorconversion) with a clear message.inspect.signaturecall per operation.BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A
TESTING INSTRUCTIONS
pytest tests/unit_tests/queries/query_object_test.pyNew tests:
cumwith onlyoperatorraisesInvalidPostProcessingErrormentioningcumandcolumns; a validcumstill works; aTypeErrorraised inside an operation is not converted. Without the fix the first new test fails (bareTypeError); with it all 48 tests in the file pass. Related suites (models/helpers_test.py,pandas_postprocessing,semantic_layers/models_test.py) show the same 8 failures with and without this change (prophet /build_like_predicate), so they are unrelated.ruff checkandruff format --checkpass.ADDITIONAL INFORMATION
🤖 Generated with Claude Code