-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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 standard acknowledgement to channels and apply usage in ibc transfer #7263
Changes from all commits
2b443d8
6fa65b2
5302fcc
23950b9
4e77eba
50f55db
b5fa71f
f159861
500af59
7223cc4
07a08fa
4782685
5eeefa3
73a4404
25bc225
9dd92de
d37f45b
76a56f9
a0bd8a4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -232,11 +232,15 @@ func (k Keeper) OnRecvPacket(ctx sdk.Context, packet channeltypes.Packet, data t | |
// acknowledgement written on the receiving chain. If the acknowledgement | ||
// was a success then nothing occurs. If the acknowledgement failed, then | ||
// the sender is refunded their tokens using the refundPacketToken function. | ||
func (k Keeper) OnAcknowledgementPacket(ctx sdk.Context, packet channeltypes.Packet, data types.FungibleTokenPacketData, ack types.FungibleTokenPacketAcknowledgement) error { | ||
if !ack.Success { | ||
func (k Keeper) OnAcknowledgementPacket(ctx sdk.Context, packet channeltypes.Packet, data types.FungibleTokenPacketData, ack channeltypes.Acknowledgement) error { | ||
switch ack.Response.(type) { | ||
case *channeltypes.Acknowledgement_Error: | ||
return k.refundPacketToken(ctx, packet, data) | ||
default: | ||
// the acknowledgement succeeded on the receiving chain so nothing | ||
// needs to be executed and no error needs to be returned | ||
return nil | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit, can you add a note on why we return nil instead of an error? |
||
} | ||
return nil | ||
} | ||
|
||
// OnTimeoutPacket refunds the sender since the original packet sent was | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -305,16 +305,11 @@ func (am AppModule) OnRecvPacket( | |
return nil, nil, sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "cannot unmarshal ICS-20 transfer packet data: %s", err.Error()) | ||
} | ||
|
||
acknowledgement := types.FungibleTokenPacketAcknowledgement{ | ||
Success: true, | ||
Error: "", | ||
} | ||
acknowledgement := channeltypes.NewResultAcknowledgement([]byte{byte(1)}) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wasn't sure what to put here since it is not specified in ICS20 at the moment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know either, but this seems like a fair non-empty success flag. |
||
|
||
if err := am.keeper.OnRecvPacket(ctx, packet, data); err != nil { | ||
acknowledgement = types.FungibleTokenPacketAcknowledgement{ | ||
Success: false, | ||
Error: err.Error(), | ||
} | ||
err := am.keeper.OnRecvPacket(ctx, packet, data) | ||
if err != nil { | ||
acknowledgement = channeltypes.NewErrorAcknowledgement(err.Error()) | ||
} | ||
|
||
ctx.EventManager().EmitEvent( | ||
|
@@ -324,6 +319,7 @@ func (am AppModule) OnRecvPacket( | |
sdk.NewAttribute(types.AttributeKeyReceiver, data.Receiver), | ||
sdk.NewAttribute(types.AttributeKeyDenom, data.Denom), | ||
sdk.NewAttribute(types.AttributeKeyAmount, fmt.Sprintf("%d", data.Amount)), | ||
sdk.NewAttribute(types.AttributeKeyAckSuccess, fmt.Sprintf("%t", err != nil)), | ||
), | ||
) | ||
|
||
|
@@ -338,7 +334,7 @@ func (am AppModule) OnAcknowledgementPacket( | |
packet channeltypes.Packet, | ||
acknowledgement []byte, | ||
) (*sdk.Result, error) { | ||
var ack types.FungibleTokenPacketAcknowledgement | ||
var ack channeltypes.Acknowledgement | ||
if err := types.ModuleCdc.UnmarshalJSON(acknowledgement, &ack); err != nil { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. shouldn't we use the cdc in the keeper? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the keeper codec is a BinaryMarshaler, thus it doesn't support JSON unmarshal |
||
return nil, sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "cannot unmarshal ICS-20 transfer packet acknowledgement: %v", err) | ||
} | ||
|
@@ -358,15 +354,23 @@ func (am AppModule) OnAcknowledgementPacket( | |
sdk.NewAttribute(types.AttributeKeyReceiver, data.Receiver), | ||
sdk.NewAttribute(types.AttributeKeyDenom, data.Denom), | ||
sdk.NewAttribute(types.AttributeKeyAmount, fmt.Sprintf("%d", data.Amount)), | ||
sdk.NewAttribute(types.AttributeKeyAckSuccess, fmt.Sprintf("%t", ack.Success)), | ||
sdk.NewAttribute(types.AttributeKeyAck, fmt.Sprintf("%v", ack)), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thoughts? or should I add a switch to check the type and emit a bool? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah we should There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will have it emit the result or error message as well There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. instead of the bool There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. updated, let me know if you agree, with specs as well There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the usage above:
We could use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah yea, I agree. Will update in a followup. We discussed standardizing IBC events on the IBC call which I think would be very useful in cases like this where there are multiple way to represent the same information |
||
), | ||
) | ||
|
||
if !ack.Success { | ||
switch resp := ack.Response.(type) { | ||
case *channeltypes.Acknowledgement_Result: | ||
ctx.EventManager().EmitEvent( | ||
sdk.NewEvent( | ||
types.EventTypePacket, | ||
sdk.NewAttribute(types.AttributeKeyAckSuccess, string(resp.Result)), | ||
), | ||
) | ||
case *channeltypes.Acknowledgement_Error: | ||
ctx.EventManager().EmitEvent( | ||
sdk.NewEvent( | ||
types.EventTypePacket, | ||
sdk.NewAttribute(types.AttributeKeyAckError, ack.Error), | ||
sdk.NewAttribute(types.AttributeKeyAckError, resp.Error), | ||
), | ||
) | ||
} | ||
|
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 we test this somehow?
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.
yes I think it should be tested by the commented tests. I wanted to uncomment the tests in a followup pr to keep this pr lightweight. There is an issue for this #7261