fix: Bidirection Object Storage for delegation#6681
fix: Bidirection Object Storage for delegation#6681Kassaking7 wants to merge 2 commits intoXRPLF:developfrom
Conversation
|
|
||
| // Add to authorized account's owner directory so the object can be found | ||
| // and cleaned up when the authorized account is deleted. | ||
| if (ctx_.view().rules().enabled(featurePermissionDelegationV1_1)) |
There was a problem hiding this comment.
In DelegateSet.cpp, we don't need this guard, because it is explicitly defined in transactions.macro, that this tx is dependant on featurePermissionDelegationV1_1. Without enabling it will return temDISABLED in preflight.
| return tecINTERNAL; // LCOV_EXCL_LINE | ||
|
|
||
| if (!view.dirRemove(keylet::ownerDir(account), (*sle)[sfOwnerNode], sle->key(), false)) | ||
| AccountID const delegator = (*sle)[sfAccount]; |
There was a problem hiding this comment.
nit: use auto const for modern c++ best practice
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
|
If only the most recent commit is unsigned, you can run:
If multiple commits are unsigned, you can run:
If you're new to commit signing, there are different ways to set it up: Sign commits with
|
|
All conflicts have been resolved. Assigned reviewers can now start or resume their review. |
src/test/app/Delegate_test.cpp
Outdated
| } | ||
|
|
||
| void | ||
| testAuthorizedAccountDeleteLocksReserve() |
There was a problem hiding this comment.
this test can be combined into the previous case:
" // Delegatee (bob) deletes account: Delegate object is cleaned up from
// both alice's and bob's owner directories."
98f7c62 to
ac6b4dd
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #6681 +/- ##
=======================================
Coverage 81.6% 81.6%
=======================================
Files 1010 1010
Lines 75982 75999 +17
Branches 7637 7631 -6
=======================================
+ Hits 61984 62003 +19
+ Misses 13998 13996 -2
🚀 New features to boost your workflow:
|
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
|
All conflicts have been resolved. Assigned reviewers can now start or resume their review. |
PeterChen13579
left a comment
There was a problem hiding this comment.
LGTM, feel free to implement the suggestion I have, if you want. I'm okay either way
High Level Overview of Change
When account A (the delegatee) is deleted, any Delegate ledger objects in other accounts' owner directories that reference A via sfAuthorize were not cleaned up, leaving dangling objects on-ledger.
This PR fixes the issue by storing the Delegate object in both the delegating account's (B) and the authorized account's (A) owner directories, mirroring the pattern used by EscrowCreate. When either party deletes their account, AccountDelete walks their owner directory, finds the ltDELEGATE entry, and deleteDelegate cleans up both sides.
Context of Change
API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)I conducted a local test using standalone mode. The core commands I had:
We can see that now we don't have delegate object for delegator after delegatee's account got deleted.