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 standard acknowledgement to channels and apply usage in ibc transfer #7263

Merged
merged 19 commits into from
Sep 9, 2020

Conversation

colin-axner
Copy link
Contributor

@colin-axner colin-axner commented Sep 8, 2020

Description

Adds standard acknowledgement definition as defined by ICS 04 and updates ibc-transfer to use this acknowledgement

closes: #6963


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 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.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@codecov
Copy link

codecov bot commented Sep 8, 2020

Codecov Report

Merging #7263 into master will increase coverage by 0.03%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##           master    #7263      +/-   ##
==========================================
+ Coverage   55.13%   55.17%   +0.03%     
==========================================
  Files         584      584              
  Lines       40506    40535      +29     
==========================================
+ Hits        22335    22366      +31     
+ Misses      16301    16300       -1     
+ Partials     1870     1869       -1     

Success: true,
Error: "",
}
acknowledgement := channeltypes.NewResultAcknowledgement([]byte{byte(1)})
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 wasn't sure what to put here since it is not specified in ICS20 at the moment.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.
(Also 1 is a nice replacement for true and auto-convert in many languages)

@@ -356,19 +352,10 @@ 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)),
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah we should

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 will have it emit the result or error message as well

Copy link
Contributor Author

Choose a reason for hiding this comment

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

instead of the bool

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated, let me know if you agree, with specs as well

Copy link
Contributor

Choose a reason for hiding this comment

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

I like the usage above:

sdk.NewAttribute(types.AttributeKeyAckSuccess, fmt.Sprintf("%t", err != nil))

We could use %v instead (or as well), but it would be nice to have them both the same (the attributes in the two different functions)

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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

@@ -336,7 +332,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 {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

shouldn't we use the cdc in the keeper?

Copy link
Collaborator

Choose a reason for hiding this comment

The 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

Copy link
Contributor

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

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

Good stuff.
Thanks @colin-axner

Success: true,
Error: "",
}
acknowledgement := channeltypes.NewResultAcknowledgement([]byte{byte(1)})
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
(Also 1 is a nice replacement for true and auto-convert in many languages)

@@ -356,19 +352,10 @@ 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)),
Copy link
Contributor

Choose a reason for hiding this comment

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

I like the usage above:

sdk.NewAttribute(types.AttributeKeyAckSuccess, fmt.Sprintf("%t", err != nil))

We could use %v instead (or as well), but it would be nice to have them both the same (the attributes in the two different functions)

}

// ValidateBasic performs a basic validation of the acknowledgement
func (ack Acknowledgement) ValidateBasic() error {
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good

Copy link
Collaborator

@fedekunze fedekunze left a comment

Choose a reason for hiding this comment

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

Looks good! 🙂

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:
Copy link
Collaborator

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?

Copy link
Contributor Author

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

return k.refundPacketToken(ctx, packet, data)
default:
return nil
Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

@@ -336,7 +332,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 {
Copy link
Collaborator

Choose a reason for hiding this comment

The 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

x/ibc-transfer/spec/01_concepts.md Outdated Show resolved Hide resolved
Copy link
Member

@AdityaSripal AdityaSripal left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Contributor

@cwgoes cwgoes left a comment

Choose a reason for hiding this comment

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

ACK

proto/ibc/channel/channel.proto Outdated Show resolved Hide resolved
@colin-axner colin-axner added the A:automerge Automatically merge PR once all prerequisites pass. label Sep 9, 2020
@mergify mergify bot merged commit b4f146b into master Sep 9, 2020
@mergify mergify bot deleted the colin/6963-standard-ack branch September 9, 2020 10:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Utilise standard acknowledgement envelope in ICS 20
5 participants