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

Spike error ack #1299

Closed
wants to merge 6 commits into from
Closed

Spike error ack #1299

wants to merge 6 commits into from

Conversation

@alpe alpe added the spike Demo to showcase an idea. label Mar 27, 2023
@alpe alpe marked this pull request as draft March 27, 2023 14:57
x/wasm/ibc.go Outdated
// the `NewErrorAcknowledgement` redacts the error message, it is
// recommended by the ibc-module devs to log the raw error as event:
ctx.EventManager().EmitEvent(
sdk.NewEvent(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we always emit an event on rcv or on only in the error case?

Copy link
Member

Choose a reason for hiding this comment

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

What about 2 events:

  1. EventTypePacketRecv: we receive a packet
  2. EventTypePacketRecvContractErr: we got a contract error which is turned into an error ack

While EventTypePacketRecvContractErr is an error, the absence of it does not mean success.

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 was also inspired by ics-20 and ics-27 . They use a single event with additional error attribute when set.

x/wasm/ibc.go Outdated
// recommended by the ibc-module devs to log the raw error as event:
ctx.EventManager().EmitEvent(
sdk.NewEvent(
types.EventTypePacketRecv,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

fyi: the event name is "ibc-acknowledgement-error" on Osmosis

Copy link
Member

@webmaster128 webmaster128 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. Some first thoughs here.

Comment on lines +150 to +151
// success ACK
return ContractConfirmStateAck(data), nil
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 this code or comment is misleading because it can be either a success or and error or a non-binary acknowledgement type. We should not try to give it any meaning.

Copy link
Contributor Author

@alpe alpe Mar 31, 2023

Choose a reason for hiding this comment

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

On packet receive, success can be defined as case 1 + 2 of #697 (comment) . The contract was able to fully handle the packet. State will be committed.


func (w ContractConfirmStateAck) Success() bool {
return true // always commit state
}
Copy link
Member

Choose a reason for hiding this comment

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

Is there any documentation what Success() in the ibcexported.Acknowledgement means?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The best source for Success() that I found is the code that calls this in ibc-go.

Copy link
Member

Choose a reason for hiding this comment

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

I raised the issue here: cosmos/ibc-go#3434

x/wasm/ibc.go Outdated
@@ -267,23 +268,38 @@ func (i IBCHandler) OnRecvPacket(
return channeltypes.NewErrorAcknowledgement(errorsmod.Wrapf(err, "contract port id"))
Copy link
Member

Choose a reason for hiding this comment

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

Is this something where we can provide a better error message than the redacted error too?

Copy link
Contributor Author

@alpe alpe Mar 31, 2023

Choose a reason for hiding this comment

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

Good 👁️ ! Unless we touch our contract-to-port mapping we should never run into this case. Either we panic here or we need to return the error event, too.
I would prefer panic to make clear in our code that this must not happen. This is not ideal as the packet may be re-submitted until timeout but it is not supposed to happen

x/wasm/ibc.go Outdated
if types.IsAcceptedEventOnRecvPacketErrorAck(e.Type) {
ctx.EventManager().EmitEvent(e)
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Do we really want to preserve those events? I might be messing something but to me it's clearer if we discard them and add all relevent information in the error event below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In a more complex contract-calls-contracts environment, the event trace may have revealed some infos to track the root cause of an error. But there are some costs of maintaining this in the future.
👌 let's drop them and keep things simple.

x/wasm/ibc.go Outdated
// the `NewErrorAcknowledgement` redacts the error message, it is
// recommended by the ibc-module devs to log the raw error as event:
ctx.EventManager().EmitEvent(
sdk.NewEvent(
Copy link
Member

Choose a reason for hiding this comment

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

What about 2 events:

  1. EventTypePacketRecv: we receive a packet
  2. EventTypePacketRecvContractErr: we got a contract error which is turned into an error ack

While EventTypePacketRecvContractErr is an error, the absence of it does not mean success.

x/wasm/ibc.go Outdated
types.EventTypePacketRecv,
sdk.NewAttribute(types.AttributeKeyContractAddr, contractAddr.String()),
sdk.NewAttribute(sdk.AttributeKeyModule, types.ModuleName),
sdk.NewAttribute(types.AttributeKeyAckSuccess, fmt.Sprintf("%t", ack.Success())),
Copy link
Member

Choose a reason for hiding this comment

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

We don't know if this us a success or not. It's just bytes from contract that can mean anything.

Copy link
Contributor Author

@alpe alpe Mar 31, 2023

Choose a reason for hiding this comment

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

Should be sdk.NewAttribute(types.AttributeKeyAckSuccess, "true"), instead

This attribute was inspired by the ics-20 impl. At this stage we do know that the ibc packet was successfully handled by the contract (and any sub-messages succeeded). The state will be committed and the Ack data stored.

alpe added 2 commits March 31, 2023 11:12
* main:
  Bump bufbuild/buf-setup-action from 1.15.1 to 1.16.0
  Use gov v1 instead of v1beta1 for new proposals (#1269)
  Update OnRecvPacket method to panic when an error is returned (#1298)
  Bump actions/checkout from 3.4.0 to 3.5.0
  Add source for Wasm magic number
@alpe
Copy link
Contributor Author

alpe commented Mar 31, 2023

Thanks for the feedback! 💐
I have added the EmitAcknowledgementEvent function to reduce some duplication. It is inspired by code in ics-27

@alpe
Copy link
Contributor Author

alpe commented Apr 21, 2023

Implemented in #1353

@alpe alpe closed this Apr 21, 2023
@alpe alpe deleted the spike_error_ack branch April 21, 2023 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spike Demo to showcase an idea.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants