-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
imp: add defensive check on WriteErrorReceipt in addition to more in-line docs on edge cases #5734
Conversation
// hasCounterpartyUpgrade returns true if a counterparty upgrade exists in store | ||
func (k Keeper) hasCounterpartyUpgrade(ctx sdk.Context, portID, channelID string) bool { |
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.
copied over same func @AdityaSripal used for HasUpgrade
but chose to leave the hasCounterpartyUpgrade
private since I don't see a reason to add it to the public API when it is used only for defensive checks in edge case scenarios (in general I think our get/set/has funcs should be private)
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5734 +/- ##
==========================================
+ Coverage 81.49% 81.52% +0.03%
==========================================
Files 199 199
Lines 15203 15229 +26
==========================================
+ Hits 12389 12415 +26
Misses 2348 2348
Partials 466 466
|
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.
🙏
@@ -55,6 +55,7 @@ func (k Keeper) WriteUpgradeInitChannel(ctx sdk.Context, portID, channelID strin | |||
|
|||
if k.hasUpgrade(ctx, portID, channelID) { | |||
// invalidating previous upgrade | |||
k.deleteUpgradeInfo(ctx, portID, channelID) |
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.
Discussed with @damiannolan. We decided to add an explicit deletion of the upgrade info when invalidating a previous attempt. Functionally this does not change the code as it stands right now because:
- we overwrite the upgrade shortly after
- no counterparty upgrade exists
but we need this change in order to keep the defensive check in WriteErrorReceipt and it prevents an accidental mistake of forgetting to delete information if more info is added to the upgrade process. So we change deletion of previous upgrade info from implicit to explicit at the gas of some extra reads/write but it'll make it harder for developers to make mistakes when changing any logic in channel upgradability
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.
no counterparty upgrade exists because we can only meaningfully run init (and by extent, its write) before we enter flushing/flushcomplete, correct?
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.
correct, since we assert the channel.State is OPEN
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 looks good to me, but I am just wondering that if we do deleteUpgradeInfo
+ WriteErrorReceipt
now, would it be possible to basically call abortUpgrade
?
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 you could @crodriguezvega but would definitely incur more gas in addition to not semantically fitting an abort which is used when channel state is either flushing/flush-complete. (maybe a refactoring could eventually be made tho)
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.
Yea, it would do extra writes to set the channel state and upgrade sequence (to the existing values). Leaving as is
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.
The final PR 🤞🏻 LFG!!!!!! 🚀
Thank you @colin-axner, amazing doc comments to save our future selves from many head scratchers ❤️
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.
Last PR before release! Exciting!
I left just a nit question.
@@ -55,6 +55,7 @@ func (k Keeper) WriteUpgradeInitChannel(ctx sdk.Context, portID, channelID strin | |||
|
|||
if k.hasUpgrade(ctx, portID, channelID) { | |||
// invalidating previous upgrade | |||
k.deleteUpgradeInfo(ctx, portID, channelID) |
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 looks good to me, but I am just wondering that if we do deleteUpgradeInfo
+ WriteErrorReceipt
now, would it be possible to basically call abortUpgrade
?
…line docs on edge cases (#5734) * imp: add defensive check + extra documentation for edge case scenarios * imp: gas optimization * self nit * imp: HasUpgrade -> hasUpgrade * fix: add explicit upgrade deletion in init --------- Co-authored-by: Carlos Rodriguez <carlos@interchain.io> (cherry picked from commit 4727e2c)
…line docs on edge cases (#5734) (#5765) * imp: add defensive check + extra documentation for edge case scenarios * imp: gas optimization * self nit * imp: HasUpgrade -> hasUpgrade * fix: add explicit upgrade deletion in init --------- Co-authored-by: Carlos Rodriguez <carlos@interchain.io> (cherry picked from commit 4727e2c) Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com>
Description
closes: #XXXX
Commit Message / Changelog Entry
see the guidelines for commit messages. (view raw markdown for examples)
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
).godoc
comments.Files changed
in the Github PR explorer.Codecov Report
in the comment section below once CI passes.