Skip to content
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 MaxTimeout condition #7521

Merged
merged 8 commits into from
Nov 1, 2024
Merged

Conversation

sangier
Copy link
Contributor

@sangier sangier commented Oct 28, 2024

Description

Add MaxTimeout condition in the SendPacket function as specified in 004

closes: #7337


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.

  • Targeted PR against the correct branch (see CONTRIBUTING.md).
  • Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/).
  • Added relevant godoc comments.
  • Provide a conventional commit message to follow the repository standards.
  • Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
  • Re-reviewed Files changed in the GitHub PR explorer.
  • Review SonarCloud Report in the comment section below once CI passes.

sequence, destChannel, err := k.sendPacket(ctx, msg.SourceChannel, msg.TimeoutTimestamp, msg.Payloads)
if err != nil {
sdkCtx.Logger().Error("send packet failed", "source-channel", msg.SourceChannel, "error", errorsmod.Wrap(err, "send packet failed"))
return nil, errorsmod.Wrapf(err, "send packet failed for source id: %s", msg.SourceChannel)
}

// Note, the validate basic function in sendPacket does the TimeoutTimestamp != 0 check and other stateless checks on the packet.
if uint64(sdkCtx.BlockTime().Unix()) > msg.TimeoutTimestamp || msg.TimeoutTimestamp > uint64(sdkCtx.BlockTime().Unix())+channeltypesv2.MaxTimeout {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are separate conditions. In the first case the msg timeout timestamp is too low. But in the second case, it is too high. But the error case only says it exceeded maximum value. Split these up so you have correct error message in each case

@@ -124,6 +134,14 @@ func (suite *KeeperTestSuite) TestMsgSendPacket() {
},
expError: channeltypesv1.ErrTimeoutElapsed,
},
{
name: "failure: timeout timestamp exceeds max allowed input",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's also add an error case for when its too low

modules/core/04-channel/v2/types/msgs.go Outdated Show resolved Hide resolved
sangier and others added 3 commits October 28, 2024 14:42
Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com>
Copy link
Member

@damiannolan damiannolan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a suggestion but happy to go either way. Would like to hear what others think!

Comment on lines 73 to 82
// Note, the validate basic function in sendPacket does the timeoutTimestamp != 0 check and other stateless checks on the packet.
// timeoutTimestamp must be less than current block time + MaxTimeoutDelta
if msg.TimeoutTimestamp > uint64(sdkCtx.BlockTime().Unix())+channeltypesv2.MaxTimeoutDelta {
return nil, errorsmod.Wrap(channeltypesv2.ErrMaxTimeoutDeltaExceeded, "timeout exceeds the maximum expected value")
}

// timeoutTimestamp must be greater than current block time
if uint64(sdkCtx.BlockTime().Unix()) > msg.TimeoutTimestamp {
return nil, errorsmod.Wrap(channeltypesv2.ErrTimeoutTooLow, "timeout is less than the current block timestamp")
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since sdk block time is a time.Time, we could leverage the time.After() / time.Before() apis from std lib here, by creating a time.Time with the absolute timeout. Would imagine it to be something like this:

// ------------------------------------------------
const timeoutDelta time.Duration = 24 * time.Hour
// ------------------------------------------------

timeout := time.Unix(int64(msg.TimeoutTimestamp), 0)
if timeout.Before(sdkCtx.BlockTime()) {
	// err timeout less than current block timestamp
}

if timeout.After(sdkCtx.BlockTime().Add(timeoutDelta)) {
	// err timeout exceeds max exp value
}

I'm fine with using uint64 absolute values too. But it might look a little less verbose to leverage the stdlib apis. Interested on input from others!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @damiannolan! That's interesting. Personally I find it a bit less readable, but happy to use it if folks prefer it!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we should use the time package as well when possible

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Find out that using the time package is the idiomatic choice in go. My bad. Changes applied as suggested!

Copy link

sonarcloud bot commented Oct 31, 2024

@AdityaSripal AdityaSripal merged commit 28b6a89 into feat/ibc-eureka Nov 1, 2024
64 of 65 checks passed
@AdityaSripal AdityaSripal deleted the stefano/7337-timeout branch November 1, 2024 10:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants