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

[Do not merge] Spike adr-8 #3359

Closed
wants to merge 1 commit into from
Closed

[Do not merge] Spike adr-8 #3359

wants to merge 1 commit into from

Conversation

alpe
Copy link
Contributor

@alpe alpe commented Mar 28, 2023

}

// NewIBCMiddleware constructor
func NewIBCMiddleware[T CallbackPacketData](next porttypes.Middleware, decoder Decoder[T], executor Executor[T], limits GasLimits) IBCMiddleware[T] {
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 choose next to be porttypes.Middleware as I plugged in ics29 middleware here. But it may make more sense to use porttypes.IBCModule instead.

next: next,
decoder: decoder,
executor: executor,
limits: limits,
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 configured limits with the middleware as this is in the adr-8 example. But when implemented into the executor, then it would be even more flexible

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adr-8 defines the limits read from the packet not defined here. So this is wrong

// see comments in https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr-008-app-caller-cbs/adr-008-app-caller-cbs.md
// todo: filter out events: https://github.com/cosmos/ibc-go/issues/3358
// todo: set event with raw error for debug as defined in ErrorAcknowledgement?
return channeltypes.NewErrorAcknowledgement(err)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are some downsides with returning error ack, that are outlined well in in the adr:

// NOTE: by returning an error acknowledgement, it is assumed that the
// base IBC application on the counterparty callback stack will be able
// to properly unmarshal the error acknowledgement. It should not expect
// some custom error acknowledgement. If it does, failed acknowledgements
// will be unsuccessfully processed which can be catastrophic in processing
// refund logic.

An alternative would be raising panic to abort the process and reverting state. The data packet would eventually run into a timeout instead

// see comments in https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr-008-app-caller-cbs/adr-008-app-caller-cbs.md
// todo: filter out events: https://github.com/cosmos/ibc-go/issues/3358
// todo: set event with raw error for debug as defined in ErrorAcknowledgement?
return channeltypes.NewErrorAcknowledgement(err)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above. Should the callback be able to overwrite the ack or is panic the way to go?

OnTimeoutPacket(ctx sdk.Context, obj T, relayer sdk.AccAddress) error
}
type GasLimits struct {
OnRecvPacketLimit *sdk.Gas
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Usage of pointers for value unset instead of 0.

)

// MyICS20Payload my random payload example
type MyICS20Payload struct {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some example data that would be extracted from memo

}

func (m MyICS20Decoder) Decode(packet channeltypes.Packet) (*MyICS20Payload, error) {
var data types.FungibleTokenPacketData
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This decoder is for ics-20 packets only and can not be plugged into ics-29 for example

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it would not be hard to provide a generic decoder. Question is if the payload type still makes sense.
Example:

type Memoable interface {
	gogoproto.Message
	GetMemo() string
}

type MyGenericMemoDecoder [T Memoable] struct {}

func (m MyGenericMemoDecoder[T]) Decode(packet channeltypes.Packet) (*MyICS20Payload, error) {
	var data T
	if err := types.ModuleCdc.UnmarshalJSON(packet.GetData(), data); err != nil {
		return nil, err
	}
	// do we need a sanity check that type was unpacked proper? like denom not empty

	if data.GetMemo() == "" {
		return nil, nil
	}
...

return &r, nil
}

var _ Executor[MyICS20Payload] = &MyICS20Callbacks{}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Executor for ics20 only. my assumption was that chains may want to customize the callbacks for each of the ibc apps.

@@ -471,7 +472,12 @@ func NewSimApp(
// create IBC module from bottom to top of stack
var transferStack porttypes.IBCModule
transferStack = transfer.NewIBCModule(app.TransferKeeper)
transferStack = ibcfee.NewIBCMiddleware(transferStack, app.IBCFeeKeeper)
transferStack = callbacks.NewIBCMiddleware[callbacks.MyICS20Payload](
ibcfee.NewIBCMiddleware(transferStack, app.IBCFeeKeeper),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is how the middleware would be integrated

@colin-axner
Copy link
Contributor

Thanks @alpe 🙏 I'm going to close this pr since there won't be any more work done for it and the design discussion has progressed past it.

@colin-axner colin-axner closed this May 4, 2023
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.

2 participants