Found while fixing #1612, deliberately kept out of that PR because the fix needs a shared traversal that does not exist yet.
#1612 fixed the NODE-level asymmetry: deleting a macro whose macro.commands could not be read now says so, the way deleting a folder whose choices could not be read already did. The SUBTREE question is still unasked.
The shape
deleteChoiceWithConfirmation (src/services/choiceService.ts) gates each warning on the deleted node's own type:
isMulti ? buildMultiWarning(choice as IMultiChoice) : "",
isMacro ? buildMacroWarning(choice as IMacroChoice) : "",
So deleting a FOLDER that contains an unreadable container gets buildMultiWarning, where hasUnreadableChildren(multi) is false (the folder itself is fine) and flattenChoices counts only what it can read. A folder holding one macro with "commands": {"0": {...}} reports
Deleting this folder will also delete everything inside it: 1 choice.
which is true and complete-sounding, and silent about the commands that are about to go with it.
Two shapes, both of them:
- a macro descendant whose
macro.commands (or whose macro) could not be read
- a nested folder whose
choices could not be read - flattenChoices reads it as empty, so a
folder hiding two choices behind {"0": ..., "1": ...} is counted as "1 folder" and nothing else
Suggested shape
One generic subtree line alongside the existing count, driven by a subtreeHasUnreadableData(choice) predicate - the node-level question #1612 answered, asked about descendants. It should compose with the count rather than replace it: the count answers "how much", the new line answers "and some of it I could not see".
The predicate wants the traversal settingsTreeHasUnreadableData (#1610) is derived from, which currently lives in src/migrations/helpers/choice-traversal.ts. src/services/ must not import src/migrations/, so this needs the walk lifted into a shared util first. That refactor is the reason this is its own issue rather than part of #1612.
Related
Found while fixing #1612, deliberately kept out of that PR because the fix needs a shared traversal that does not exist yet.
#1612 fixed the NODE-level asymmetry: deleting a macro whose
macro.commandscould not be read now says so, the way deleting a folder whosechoicescould not be read already did. The SUBTREE question is still unasked.The shape
deleteChoiceWithConfirmation(src/services/choiceService.ts) gates each warning on the deleted node's own type:So deleting a FOLDER that contains an unreadable container gets
buildMultiWarning, wherehasUnreadableChildren(multi)is false (the folder itself is fine) andflattenChoicescounts only what it can read. A folder holding one macro with"commands": {"0": {...}}reportswhich is true and complete-sounding, and silent about the commands that are about to go with it.
Two shapes, both of them:
macro.commands(or whosemacro) could not be readchoicescould not be read -flattenChoicesreads it as empty, so afolder hiding two choices behind
{"0": ..., "1": ...}is counted as "1 folder" and nothing elseSuggested shape
One generic subtree line alongside the existing count, driven by a
subtreeHasUnreadableData(choice)predicate - the node-level question #1612 answered, asked about descendants. It should compose with the count rather than replace it: the count answers "how much", the new line answers "and some of it I could not see".The predicate wants the traversal
settingsTreeHasUnreadableData(#1610) is derived from, which currently lives insrc/migrations/helpers/choice-traversal.ts.src/services/must not importsrc/migrations/, so this needs the walk lifted into a shared util first. That refactor is the reason this is its own issue rather than part of #1612.Related