feat(manager): read the subtree from the agent, and surface a delete that left host copies behind - #262
Merged
Conversation
`vta/contexts/preview-delete/1.0` gained `subContexts` in trust-tasks 0.21.4, so the console no longer derives the cascade from the context list — the agent decides what the deletion reaches, so the agent is the one that should name it. `vta/contexts/delete/1.0` gained `daemonCleanupErrors`: DIDs whose host copy the agent could not confirm removing. A success carrying a non-empty list is not a finished deletion, and the spec says a consumer MUST surface it, so it is returned rather than dropped. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
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.
Follows #261. Takes the two members trust-tasks 0.21.4 added (trustoverip/dtgwg-trust-tasks-tf#513), served by OpenVTC/verifiable-trust-infrastructure#1577.
The console stops deriving the cascade
#261 named the sub-contexts a delete would take, but had to work them out from
contexts/listand match paths itself, becausevta/contexts/preview-delete/1.0had no member for them. It does now (subContexts), sodescendantsOfgoes.This matters beyond tidiness. The agent decides what its cascade reaches; a console that computes that independently is a second implementation of the rule, sitting in front of an irreversible prompt. It agreed today — nothing kept it agreeing, and the disagreement would have shown up as a confirmation dialog that understated what was about to be destroyed.
A delete that isn't finished says so
contextDeletenow returnsdaemonCleanupErrors: the DIDs whose records are gone while their published logs may still be served. A success that is not a completed deletion, which the specification says a consumer MUST surface — and which the client was dropping on the floor.Tests
The render tests feed
subContextsthrough the agent double instead of the records list, so what they pin is the panel's reading of the agent's answer rather than its own path matching. Two new core tests cover the cleanup report in both casings.npm run lint(tsc -b, all workspaces) — cleannpm test— 1528 tests across five workspaces, 0 failuresnpm run build— cleanOrdering
Independent of #1577 in the sense that nothing breaks if this lands first: the members are optional, absent reads as empty, and the panel renders correctly either way. But the console only shows sub-contexts once an agent on #1577 is serving them, so there is no reason to land this ahead of it.