fix(api): advertise only the time grains Prophet can resolve - #43710
fix(api): advertise only the time grains Prophet can resolve#43710SEPURI-SAI-KRISHNA wants to merge 1 commit into
Conversation
Code Review Agent Run #a77d73Actionable 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 |
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #43710 +/- ##
=======================================
Coverage 79.24% 79.25%
=======================================
Files 2888 2888
Lines 166446 166449 +3
Branches 38529 38529
=======================================
+ Hits 131908 131911 +3
Misses 32045 32045
Partials 2493 2493
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
Fixes #43356.
ChartDataProphetOptionsSchema.time_grainvalidates againstget_time_grain_choices(), which mergesbuiltin_time_grainswith theoperator-configured
TIME_GRAIN_ADDONS.prophet()then resolves the grainthrough
PROPHET_TIME_GRAIN_MAP, a static map that cannot contain anoperator's arbitrary addon key. So a configured custom grain passes schema
validation and then fails at the lookup, the API advertises a forecast it
cannot serve.
Reproducing on
masterwithTIME_GRAIN_ADDONS = {"PT7M": "7 minute"}:The addon keys are arbitrary ISO-8601 durations, so the static map cannot
simply be extended to cover them, and converting them to pandas frequencies at
runtime is not total,
P0.25Ybeing the obvious case. That leaves the otheroption the issue identifies: publish only what the operation can resolve.
This adds
get_prophet_time_grain_choices(), returning the keys ofPROPHET_TIME_GRAIN_MAP, and points the Prophet field's validator at it.get_time_grain_choices()is deliberately left alone, it is shared withtime_grain_sqlaonChartDataExtrasSchema, where addon grains arelegitimately supported, and narrowing it there would be a regression.
This widens the published set as well as narrowing it.
PT0.5H(
HALF_HOUR) andP0.25Y(QUARTER_YEAR) are in the map but not inbuiltin_time_grains, so they were previously rejected by the schema despiteresolving fine in
prophet(). They are now accepted. Net effect on a defaultdeployment is 19 advertised grains -> 21, with every one of them resolvable.
No working request changes behaviour: the grains this removes from the spec
never produced a forecast.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A, backend-only fix.
TESTING INSTRUCTIONS
Three tests are added:
test_prophet_schema_advertises_only_resolvable_grainsasserts the field'sown
OneOfchoices equal the map's keys. It reads the validator rather thanthe helper, so re-pointing the field back at
get_time_grain_choices()failshere rather than silently reintroducing the bug.
test_prophet_rejects_addon_grain_accepted_by_time_grain_sqlaconfiguresTIME_GRAIN_ADDONS = {"PT7M": "7 minute"}and asserts the addon is stilladvertised by the shared helper while the Prophet schema rejects it. This is
the reported bug, and it pins the "do not narrow the shared helper"
constraint.
test_prophet_accepts_every_mapped_graincovers the five grains that nowload and resolve, including the two newly advertised aliases.
The three pre-existing
time_grainassertions are unchanged and still pass —P1Dremains valid andinvalid_grainremains rejected.ADDITIONAL INFORMATION
Note for reviewers: #43206 also edits
ChartDataProphetOptionsSchema, aboutfifty lines below this change (
monthly_seasonality->daily_seasonality,plus
index). Separate hunks, so the two should merge cleanly, but whicheverlands second may want a rebase.