mirror of
https://github.com/apache/superset.git
synced 2026-08-05 13:32:41 +00:00
8bd085613f
Two related bugs found in a post-merge self-review, both stemming from multiple MigrateViz subclasses sharing one target_viz_type (e.g. both MigrateLineChart and MigrateCompareChart migrate onto echarts_timeseries_line): - MigrateViz.downgrade()'s SQL filter (target_viz_type + a form_data_bak marker) is coarse by necessity and matches slices from ANY subclass sharing that target. Running e.g. `compare`'s downgrade would therefore also revert already-settled `line`-sourced slices back to the legacy `line` viz_type -- a plugin this same PR deletes. Each row's own form_data_bak was still correct (no data corruption), but the migration wasn't independently revertible the way its name implies. Fixed by checking form_data_bak["viz_type"] == cls.source_viz_type in downgrade_slice() before touching a row -- the backup already records which migration produced it, no new field needed. - The `superset viz-migrations downgrade --id` CLI path had the same root cause one level up: PREVIOUS_VERSION was keyed by target_viz_type, so building it from MIGRATIONS silently let the last-registered subclass for a shared target win the dict, and `migrate_by_id` would invoke the wrong class's downgrade_slice for any chart from the losing subclass. With the fix above, that would have started silently no-op'ing instead of misfiring, which just relocated the bug. Removed PREVIOUS_VERSION entirely and look the migration up by the slice's own backed-up source viz_type via MIGRATIONS (already correctly keyed 1:1 by source type). Added a regression test exercising the exact MigrateLineChart / MigrateCompareChart collision. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>