xcm: fix for DenyThenTry Barrier #7169
Conversation
|
@yrong overall looks good so far, I was also thinking about another trait for that like this |
…adot-sdk into fix-for-deny-then-try
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Clara van Staden <[email protected]>
Co-authored-by: Clara van Staden <[email protected]>
| instructions: &mut [Instruction<RuntimeCall>], | ||
| max_weight: Weight, | ||
| properties: &mut Properties, | ||
| ) -> Option<ProcessMessageError>; |
There was a problem hiding this comment.
nitish: using Result instead of Option would be idiomatic here.
| ) -> Option<ProcessMessageError>; | |
| ) -> Result<(), ProcessMessageError>; |
There was a problem hiding this comment.
The original version is something like that. @bkontur left some concerns in
#7169 (comment) which make sense to me, so we made the change accordingly.
There was a problem hiding this comment.
I understand it better with the Option because seeing Some(_) makes me guess it will be denied but seeing Ok(_) makes me doubt whether or not it's okay to deny or okay to pass.
To clear up all possible misunderstanding we could use a custom enum:
enum DenyResult {
Deny,
DontDeny,
}Might be overkill though.
There was a problem hiding this comment.
Miss the comment in another thread #7169 (comment)
@franciscoaguirre seems others prefer more to Result<(), ProcessMessageError>, but thanks for the comment here anyway.
…adot-sdk into fix-for-deny-then-try
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
…adot-sdk into fix-for-deny-then-try
| instructions: &mut [Instruction<RuntimeCall>], | ||
| max_weight: Weight, | ||
| properties: &mut Properties, | ||
| ) -> Option<ProcessMessageError>; |
There was a problem hiding this comment.
I understand it better with the Option because seeing Some(_) makes me guess it will be denied but seeing Ok(_) makes me doubt whether or not it's okay to deny or okay to pass.
To clear up all possible misunderstanding we could use a custom enum:
enum DenyResult {
Deny,
DontDeny,
}Might be overkill though.
|
/cmd fmt |
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
|
@acatangiu Please check if there is anything important that I should address for merging. |
Resolves (partially): #7148 (see Problem 1 -
ShouldExecutetuple implementation andDenyfilter tuple)This PR changes the behavior of
DenyThenTryfrom the patternDenyIfAllMatchtoDenyIfAnyMatchfor the tuple.I would expect the latter is the right behavior so make the fix in place, but we can also add a dedicated Impl with the legacy one untouched.
TODO
DenyReserveTransferToRelayChainDenyThenTryas discussed here and update documentation if needed