-
Notifications
You must be signed in to change notification settings - Fork 411
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
Spike error ack #1299
Conversation
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( |
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.
Should we always emit an event on rcv or on only in the error case?
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.
What about 2 events:
- EventTypePacketRecv: we receive a packet
- 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.
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.
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, |
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.
fyi: the event name is "ibc-acknowledgement-error"
on Osmosis
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.
Good stuff. Some first thoughs here.
// success ACK | ||
return ContractConfirmStateAck(data), nil |
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.
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.
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.
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 | ||
} |
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.
Is there any documentation what Success()
in the ibcexported.Acknowledgement
means?
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.
The best source for Success()
that I found is the code that calls this in ibc-go.
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.
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")) |
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.
Is this something where we can provide a better error message than the redacted error too?
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.
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) | ||
} | ||
} |
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.
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.
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.
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( |
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.
What about 2 events:
- EventTypePacketRecv: we receive a packet
- 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())), |
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.
We don't know if this us a success or not. It's just bytes from contract that can mean anything.
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.
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.
Thanks for the feedback! 💐 |
Spike error ack - Updates
Implemented in #1353 |
Spike that covers: