-
Notifications
You must be signed in to change notification settings - Fork 620
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
Add pruning logic, implementation in message server. #5444
Add pruning logic, implementation in message server. #5444
Conversation
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 know this is still in draft, but left just a couple of comments. :)
modules/core/keeper/msg_server.go
Outdated
|
||
// update pruning sequence in store | ||
k.ChannelKeeper.SetAcknowledgementPruningSequence(ctx, msg.PortId, msg.ChannelId, sequence) | ||
|
||
return &channeltypes.MsgPruneAcknowledgementsResponse{}, nil |
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.
Should we update the message to return the number of acks and receipts that were pruned?
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 log it instead? I have no strong preference, down to update it if people have one, it really depends on how and if others consume this information.
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.
Let's do logging at least then.
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.
ahah too late! I've changed this to return pruned, left. I think it made a lot of sense since we can work out this info.
// | ||
// The pruningSequence keeps track of the packet acknowledgement that can be pruned next. When the pruning sequence reaches | ||
// the last send sequence, pruning is complete. | ||
func (k Keeper) PruneAcknowledgements(ctx sdk.Context, portID, channelID string, limit, pruningSequence uint64) uint64 { |
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.
Should the naming reflect that it also prunes packet receipts?
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.
it most definitely should!
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.
PruneStalePacketData
? throwing ideas in the ether.
Note: should probably rename a bunch of things AckPruningSequence -> PruningSequence
etc. Can do it in this PR but will increase noise.
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.
PruneStalePacketData
sounds good to me.
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.
sounds good to me! Probably best to leave it as a slight follow up (to rename proto msg too) unless people don't mind the extended diff here.
2b8147f
to
449cc8b
Compare
449cc8b
to
b9acc51
Compare
Holding off on review until PRs are cascaded! |
56edec6
to
98f10d1
Compare
a99fa8f
to
de6ada4
Compare
de6ada4
to
5e646ba
Compare
5e646ba
to
6b5ada0
Compare
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 this is looking very good. Nice work, @charleenfei.
modules/core/keeper/msg_server.go
Outdated
|
||
// update pruning sequence in store | ||
k.ChannelKeeper.SetAcknowledgementPruningSequence(ctx, msg.PortId, msg.ChannelId, sequence) | ||
|
||
return &channeltypes.MsgPruneAcknowledgementsResponse{}, nil |
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.
Let's do logging at least then.
Co-authored-by: Carlos Rodriguez <carlos@interchain.io>
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'm opening this PR for reviewz, I'm off from tomorrow so if people want to push nits/fixes on this, feel free to do so!
Oh, final note: the message should ideally be renamed, won't do it here since its already enough of a change and the name change diff would bring all sort of random files for additional review. Opening an issue for it now (#5473) but if people don't mind it being pushed here, please do!
} | ||
|
||
// sendMockPacket sends a packet from source to dest and acknowledges it on the source (completing the packet lifecycle). | ||
// Question(jim): find a nicer home for 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.
so many people moved why not sendMockPackets
? This and UgradeChannel
seem like nice little helpers to have but they should do with a better home.
inb4: these already exist someplace and I missed em.
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.
just realised I should've replied here instead of a new comment :D https://github.com/cosmos/ibc-go/pull/5444/files#r1434023684
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.
Can also look into moving this to a more generalized testing func in the testing pkg at some point! :)
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.
LGTM, I absolutely love the test coverage, really nice job! Had just a few small suggestions for tweaks in the tests but nothing major
nil, | ||
}, | ||
{ | ||
"success: stale packet state pruned, two upgrades", |
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.
nice consideration!
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.
Just leaving two initial comments on the proto api.
Will review fully after lunch and I can also help push any follow up commits to the branch!
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.
Approving as I only have a minor nit on optimistically deleting
Ok with any of the proposed names. Either the current, or Damian's suggestions. Let's come to final consensus and change once so we don't keep changing on every new opinion 😛
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.
LGTM!! 🚀 🎉
Awesome work @DimitrisJim and amazing work on the testing, looks super thorough!
Thanks to everyone for their commits and reviews too! ❤️
} | ||
|
||
// UpgradeChannel performs a channel upgrade given a specific set of upgrade fields. | ||
// Question(jim): setup.coordinator.UpgradeChannel() wen? |
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.
100 emoji
} | ||
|
||
// sendMockPacket sends a packet from source to dest and acknowledges it on the source (completing the packet lifecycle). | ||
// Question(jim): find a nicer home for 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.
Can also look into moving this to a more generalized testing func in the testing pkg at some point! :)
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.
Really top notch work @DimitrisJim! 👑 Thank you so much!!
|
||
if tc.expErr == nil { | ||
suite.Require().NoError(err) | ||
suite.Require().NotNil(resp) |
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.
super nit suggestion: we could assert the response values are as expected by sending a packet and asserting 1 packet receive is pruned
suite.chainA.GetContext(), | ||
path.EndpointA.ChannelConfig.PortID, | ||
path.EndpointA.ChannelID, | ||
5, |
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.
5, | |
17, |
should we be attempting to prune post upgrade packet sends by setting it to a higher limit? To show that it safely returns after all possible have been pruned?
if !k.HasPruningSequenceStart(ctx, portID, channelID) { | ||
return 0, 0, errorsmod.Wrapf(types.ErrPruningSequenceStartNotFound, "port ID (%s) channel ID (%s)", portID, channelID) | ||
} | ||
|
||
pruningSequenceStart := k.GetPruningSequenceStart(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.
I find it odd that the get func here doesn't return a found
bool. But I guess it is fine
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, I found I had the same reaction too!
But apparently the argument is saving gas with a Has
check? :D lol
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.
Isn't this increasing gas? I suspect the majority of calls to this function to have the sequence set, which results in extra gas costs
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 it would increase gas in the successful case of it being set. And save gas in the scenario of it not being set
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! Looking at the gas config earlier though, this should be miniscule enough to not warrant it, we can totally switch it up to have get return val, found as usual, my bad in adding it this way.
} | ||
) | ||
|
||
testCases := []struct { |
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.
could we add a test case where a middle sequence doesn't have an ack stored (because a timeout occurred)?
Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## 04-channel-upgrades #5444 +/- ##
=======================================================
+ Coverage 80.82% 80.90% +0.07%
=======================================================
Files 197 197
Lines 15195 15234 +39
=======================================================
+ Hits 12282 12325 +43
+ Misses 2441 2437 -4
Partials 472 472
|
Opened #5476 for testing improvements. Agree with @colin-axner's points! |
Description
closes: #3937
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.