feat(server): report renewal targets dropped by an identity change - #423
Merged
Conversation
A pass silently discarded targets promised by a previous identity. It counted them in a log line and returned only the survivors, so a host saw a target stop appearing in `outcomes` with nothing saying why. Raw account targets are exactly the ones that do not survive a rotation, and the surface has no way to list the ledger, so there was no way to notice or recover. `StatementRenewalReport` now carries the labels it dropped. The information was already in hand at the pruning site; only the count reached the caller. Labels come from one function shared with `resolve_target`, so a pruned entry reads the same as a renewed one, and it derives without an active session because pruning is decided before the ledger is resolved. Reviewed twice on #417 as a gap this leaves open. A reader and an untrack are still missing, tracked separately: those need design decisions this does not.
filvecchiato
approved these changes
Aug 17, 2026
Imod7
reviewed
Aug 17, 2026
Pruning rewrites the whole ledger but read it outside the lock, so a `track_targets` landing in the gap was overwritten by a view that predated it and that account was tracked nowhere afterwards. `track_targets` already holds the lock across its own read-modify-write; this now matches. The new test fails without the change, losing the concurrently tracked target outright. The dropped labels are logged where the prune happens rather than only returned. Every step between there and the report can fail, and `run_tick` reads only the exhaustion flag and the outcome count, so the log is the one place a prune is recorded unconditionally. The durable version belongs with the reader. A prune is not a failed renewal, so it no longer borrows the failure event, which rendered it red beside chain rejections and counted toward nothing. There is an `AllowanceRenewalPruned` event and a `pruned` count in the summary, so the all-foreign case reads as three dropped targets rather than three failures followed by "no tracked allowance targets". Both host READMEs said a pruned target was absent from the report one sentence before saying it was listed in it. The stale half is gone and the examples read `report.pruned`.
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
3 participants
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.
A renewal pass silently discarded targets promised by a previous identity. It counted them in a log line and returned only the survivors, so a host saw a target stop appearing in
outcomeswith nothing saying why. RawAccounttargets are exactly the ones that do not survive a rotation, and the surface has no way to list the ledger, so there was no way to notice or recover.StatementRenewalReportcarries the labels it dropped. The information was already in hand at the pruning site; only the count reached the caller, so this is one additive field rather than new API surface.Labels come from one function shared with
resolve_target, so a pruned entry reads the same as a renewed one, and it derives without an active session because pruning is decided before the ledger is resolved against entropy.The CLI reports each dropped target with the reason and what to do about it. Both host READMEs now point at
report.prunedinstead of telling hosts a pruned entry is undetectable.Scope
Raised twice in review on #417. A reader and an untrack are still missing and are tracked separately: those need decisions this does not, and the report may reduce how much a reader is worth.
Verification
Live through the CLI:
/renewagainst the People chain, period 20682, three targets renewed. The two pruning tests now assert the reported labels, not just that entries were dropped.