Repository navigation
fix: restore by one rule for every error type, and never overwrite a backup - #10
Merged
Merged
Conversation
…backup - A chart update Superset rejected after the import left the dashboard half-updated, while a connection drop at the same step restored it. Both now restore the backup. - A non-Superset error (a bug) mid-build skipped the restore and surfaced as a traceback without the backup path. It now follows the same rule and returns the normal report. - Failures after the chart updates (linkage, scopes, queries) still leave the new version live, unchanged. - Backup names go to the microsecond and use exclusive create, so two applies in one second no longer overwrite the first backup. Tests: four offline cases (each fails on main), and three new live fault scenarios in tools/faultline.py (import-time bug, rejected and dropped in-place chart update) run on 4.1.4, 5.0.0 and 6.1.0 in CI.
2 of 3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item A from the 0.2.0 triage: rollback after a failed build.
The rule, now applied the same way to every error type: a failure in the prepare or import step, in-place chart updates included, puts the backup back automatically; a failure after that (linkage, filter scopes, chart queries) leaves the new version live, with the backup path in the report for
chartwright restore.What was wrong
What changed
apply.py: restore on a failed in-place chart update; a catch-all that follows the same rule and returns the normal report;write_backup()names backups to the microsecond (20261003T141502.123456.zip) with exclusive create.tests/test_apply_rollback.py: four offline cases, each of which fails on main.tools/faultline.py: three new live scenarios (an import-time bug, a rejected in-place chart update, a dropped in-place chart update), each required to auto-restore and leaveplanclean against the pre-apply spec. CI runs them on Superset 4.1.4, 5.0.0 and 6.1.0.VERIFICATION.md(fault-injection section, test count) andCHANGELOG.md.The guides in #9 that describe a failed chart update as leaving the new version live will be updated there.
Offline suite: 347 passed.