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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce and Implement
VestedTransfer
Trait #5630Introduce and Implement
VestedTransfer
Trait #5630Changes from 5 commits
79671a4
d47c240
75da32e
7e825db
24b2832
e784ecb
65ae2c2
39be304
c690ab8
011c6ae
03efc85
3760a94
0843474
e7ac025
cfe000f
2a66893
e5ecc12
57bdb07
27ce63b
31724ac
016b209
2b83654
a66f794
3a1cf6a
5a8fcb9
62a3676
2b216c0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that everyone calling this will need to use
transactional
to revert the changes if there is an error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
everyone in frame uses transactional? what am I missing?
All code inside the runtime now assume we can error at any point in the code. when this was written, it wasn't the case, hence the need to "double check"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But
VestedTransfer::vested_transfer
function is not a pallet call. If someone implements an error recovery logic it can get messy I suppose.Maybe it is standard practice now, but I would add a small comment on top of
do_vesting_transfer
that the storage is dirty in case the method becomes public in the future.And in the doc of
VestedTransfer::vested_transfer
I would also write that the storage can be dirty when error is returned.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. If someone handles the error, it will not be transactional. Or you do the transactional handling explicitly in the implementation of the trait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I really didn't consider this. I have explicitly added a transactional layer to the trait implementation.
I feel there must be many traits in Polkadot SDK which are vulnerable to the same problem, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay i brought back this check, not looking to cause an issue in Polkadot due to small optimization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that in general people should probably rarely recover from a dispatch error, and it would be simpler to require the caller to rollback.
Maybe we can make a transition with a new type:
DispatchErrorDirty
orDispatchErrorToRollback
which means that the storage is dirty and should be rollbacked to handle the error manually.Or maybe everybody already assume that a
DispatchError
can have a dirty storage.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this kind of direction would be nice overall imo