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
Fix and simplify reverts of forwarding state #6574
Fix and simplify reverts of forwarding state #6574
Changes from 3 commits
6305f3f
b13dae4
f25c918
492ecac
7770197
bcf359d
d867a5e
a092154
0f4c22c
13270d8
e5b9d78
e75c29e
3123d67
cbad515
d3a60fc
45c7efa
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.
I am wondering if we can structure the code in a different way to have fewer helper functions, since some of them are pretty thin and only called once, so not sure if they really add a lot of value... I was thinking of having one helper function like this (naming, as always is up for debate):
And then wherever is called, either on error ack or timeout, we do something like this (adjusting the message in the ack accordingly):
What do people think?
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 think I prefer this suggestion to reduce the number of small helper fns
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.
yup, also wouldn't mind in-lining these smaller fns in the
OnAck/OnTimeout
methods but see the logic of keeping most forwarding logic in this file.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.
Hm, it seems this would only get rid of
acknowledgeForwardedPacket
function. I'd rather not inline this becauseGetCapability
hurts readability a lot in my opinion. I want to seeGetCapability
in as few places as possible. Could you reconsider this?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.
We could probably handle success/error/timeout all in one function. Something like this:
And then getting the capability is in a single place.
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 doesn't address the timeout case. I am strongly against this suggestion because coupling acknowledgement, error handling, and reversion into a single function overcomplicates the code imo. I'd rather have multiple easy to understand helper functions.
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 might be wrong, but I think it would cover it. In
OnTimeoutPacket
You would do something like: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.
think its fine if we leave as is for now and kick this can for down the road. These are all private fns and can be changed after the fact without issue. Lets not block on it for time being?
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.
Ah ok, it does handle it. Yeah, lets kick this down the road, I do like functions with simple responsibilities.
Although it may seem ok to merge them now, we might want to perform additional logic in the future depending on whether it was a timeout or not, such as emitting events. Then having these separated could be helpful.
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.
Maybe it's worth for clarity's sake to mention that the receiver is the forwarding account and that the vouchers are minted also on the forwarding account.
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.
Good one to call
escrowCoin
here to update the total amount in escrow for the denom. 🥇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.
Do we want to wrap the errors returned from this function in some error like
ErrRevert...
?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.
we don't really do any additional wrapping with errors returned from
refundPacketTokens
so I don't think it's strictly necessary to add an additional error type here