Repository navigation
Add a restore of the synced fields from a stored snapshot - #2
Merged
Merged
Conversation
The first apply of the sync writes about 1700 values across the boards and issues. A restore sets the synced fields back to the values of a stored snapshot.json, so a wrong bulk apply can be undone. python -m board_sync.restore reads all places, plans one write per difference (the stored value, or a clear), and prints the plan with a plan id. --apply writes only when --expect names the plan id of the run, needs --report, writes the report before the first write and again at the end, and stops after 5 failed writes in a row. Issues, places and fields that are in only one of the two reads are counted in the report. synced_names moves to core, where missing_fields uses it too. The README lists the steps around a restore. It names the commit for snapshot.json and for state.json, and says to clear bulk_keys, bulk_idle and failures in the replaced state.json: a state.json saved after the undone writes makes the next run clear original values, and an older approval lets a scheduled run write the undone values again.
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.
Summary
Adds
python -m board_sync.restore, which sets the synced fields back to the values of a storedsnapshot.jsonfrom the state repository. I want this in place before the first bulk apply, so a wrong apply can be undone.Changes
board_sync/restore.py: plan the writes that return each synced field to its stored value (or clear it), print the plan with a plan id, and apply it with--apply --expect <plan id> --report <file>. The report is written on every path, before the first write and at the end; the run stops after 5 failed writes in a row; skipped values and issues, places and fields in only one read are counted.board_sync/core.py:synced_names(place), used bymissing_fieldsand by the restore.tests/test_restore.py: plan cases, the realgithub.writemutations through a recording client, plan id, apply, partial failure, failures in a row, interrupted run, report paths, setup errors, command line.snapshot.jsonandstate.json, and the approval fields to clear..gitignore:restore.txt.Validation
coverage run -m pytest -q: 163 passed;coverage report:board_sync/restore.py100% of lines and branches, total 99%.ruff check .andruff format --check .: clean.core.plan(old, {})andrestore.plan(old, applied)on the snapshot of the dry run https://github.com/Interra-Project/board-sync/actions/runs/39748240410 (304 issues): the 1687 planned sync writes, applied in memory, give 1687 restore writes on the same issues, places and fields with the stored values, and a second restore plan is empty.python -m board_sync.restore snapshot.jsonagainst the live boards: 0 planned writes, since nothing changed after the snapshot; with 1 value changed in a copy of the snapshot, exactly 1 planned write.core.plan: with thestate.jsonfrom after the apply, 1137 writes of which 987 clear stored values; with no state, the 1687 writes again, which stop at the limit of 20. With the 1687 write keys left inbulk_keys,plan_and_applywrites 400 of them without a stop, which is why the README clears that field.Not checked
No
--applyagainst the live boards: the restore has not written a value yet.