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

chore: adding implementation for SendPacket message server #7383

Conversation

chatton
Copy link
Contributor

@chatton chatton commented Oct 2, 2024

Description

This PR adds the bulk of the implementation for the SendPacket message server V2 implementation. There are a few follow up items that need to be completed before this handler is complete. I will link these in follow up issues.

Part of: #7359

closes: #7353


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.

@chatton chatton marked this pull request as ready for review October 2, 2024 16:02
@@ -14,6 +14,14 @@ func NewTimeout(height clienttypes.Height, timestamp uint64) Timeout {
}
}

// NewTimeoutWithTimestamp creates a new Timeout with only the timestamp set.
func NewTimeoutWithTimestamp(timestamp uint64) Timeout {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we only care about timestamp in the eureka spec

timeoutTimestamp uint64,
data []channeltypesv2.PacketData,
) (uint64, error) {
// TODO: add aliasing logic
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@chatton create an issue for this!

@@ -0,0 +1,25 @@
package types
Copy link
Contributor Author

Choose a reason for hiding this comment

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

duplicate from packet-server keeper

// OnSendPacket is executed when a packet is being sent from sending chain.
// this callback is provided with the source and destination IDs, the signer, the packet sequence and the packet data
// for this specific application.
OnSendPacket(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I figure we can add them one method at a time

@@ -108,6 +108,28 @@ type IBCModule interface {
) error
}

// IBCModuleV2 defines an interface that implements all the callbacks
// that modules must define as specified in IBC Protocol V2
type IBCModuleV2 interface {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

not convinced this is the best place for this interface, open to suggestions! (Also do we want V2 in the name? )

Copy link
Contributor

Choose a reason for hiding this comment

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

It really should be referenced as api.IBCModule, I wonder if it makes sense to create the api directory now, would be a weird partial transition if you didn't move over the light client module

Main dependency concern is that if you move this api elsewhere, you may need to define interfaces or move the concrete implementations

@@ -0,0 +1,10 @@
package types
Copy link
Contributor Author

Choose a reason for hiding this comment

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

duplicate from packet-server

errorsmod "cosmossdk.io/errors"

clienttypes "github.com/cosmos/ibc-go/v9/modules/core/02-client/types"
channeltypes "github.com/cosmos/ibc-go/v9/modules/core/04-channel/types"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we want to a new timeout type that lives just in channeltypesv2? To not need this dependency

Copy link
Contributor

Choose a reason for hiding this comment

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

lets keep track of it in issue and close if it seems overkill?

Copy link
Contributor

Choose a reason for hiding this comment

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

the timeout being referenced by the light client interface seems unavoidable to me, so I think that's the main consideration. Checkout #7055 for context on how this might look going forward as well. In #7055, you could remove the timeout type and separate legacy behaviour by providing the timestamp/height type separately

timeoutTimestamp uint64,
data []channeltypesv2.PacketData,
) (uint64, error) {
// TODO: add aliasing logic https://github.com/cosmos/ibc-go/issues/7387
Copy link
Contributor

Choose a reason for hiding this comment

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

any reason why we can't just add the fallback now?

Comment on lines 26 to 27
sdkCtx.Logger().Error("send packet failed", "error", errorsmod.Wrap(err, "Invalid address for msg Signer"))
return nil, errorsmod.Wrap(err, "Invalid address for msg Signer")
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
sdkCtx.Logger().Error("send packet failed", "error", errorsmod.Wrap(err, "Invalid address for msg Signer"))
return nil, errorsmod.Wrap(err, "Invalid address for msg Signer")
sdkCtx.Logger().Error("send packet failed", "error", errorsmod.Wrap(err, "invalid address for msg Signer"))
return nil, errorsmod.Wrap(err, "invalid address for msg Signer")

errorsmod "cosmossdk.io/errors"

clienttypes "github.com/cosmos/ibc-go/v9/modules/core/02-client/types"
channeltypes "github.com/cosmos/ibc-go/v9/modules/core/04-channel/types"
Copy link
Contributor

Choose a reason for hiding this comment

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

the timeout being referenced by the light client interface seems unavoidable to me, so I think that's the main consideration. Checkout #7055 for context on how this might look going forward as well. In #7055, you could remove the timeout type and separate legacy behaviour by providing the timestamp/height type separately

Copy link
Contributor

Choose a reason for hiding this comment

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

do we want to name this relay.go? I think this currently mimics the name in channel/keeper/ though right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah I think we should call it relay.go

}

// construct packet from given fields and channel state
packet := channeltypesv2.NewPacket(sequence, sourceID, counterparty.CounterpartyChannelId, timeoutTimestamp, data...)
Copy link
Contributor

Choose a reason for hiding this comment

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

do we want to name counterparty.CounterpartyChannelId as destID? Ditto for clientId := counterparty.ClientId. We currently have this assignments in the relay.go of packet-server and feel like they would be nice to do here too (will help with refactor of Counterparty -> Channel down the line)

Leaving it up to you.

@chatton
Copy link
Contributor Author

chatton commented Oct 3, 2024

Sorry guys! I ended up making a few more changes,

  • I added the aliasing logic as suggested
  • included some tests (wiring needed to happen to ibc core keeper to allow this)
  • moved module into api dir (great suggestion @colin-axner )

Copy link
Contributor

@DimitrisJim DimitrisJim left a comment

Choose a reason for hiding this comment

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

ack changes, slam it!

Copy link

sonarcloud bot commented Oct 3, 2024

@chatton chatton merged commit ef8b0ab into feat/ibc-eureka Oct 3, 2024
63 of 65 checks passed
@chatton chatton deleted the cian/issue#7359-investigate-addition-of-ibcmodule-v2-application-interface branch October 3, 2024 14:23
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