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

Callbacks Eureka #7934

Merged
merged 20 commits into from
Feb 10, 2025
Merged

Callbacks Eureka #7934

merged 20 commits into from
Feb 10, 2025

Conversation

AdityaSripal
Copy link
Member

Description

The following is a cherrypick of relevant commits from #7927

Please pay close attention while reviewing this PR. It is recommended to review the ibc callbacks v1 middleware in parallel and ensure all equivalent checks and logic are being made

closes: #7855


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 the 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 and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/).
  • Added relevant godoc comments.
  • Provide a conventional commit message to follow the repository standards.
  • Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
  • Re-reviewed Files changed in the GitHub PR explorer.
  • Review SonarCloud Report in the comment section below once CI passes.


return IBCMiddleware{
app: packetDataUnmarshalerApp,
writeAckWrapper: writeAckWrapper,
Copy link
Member Author

Choose a reason for hiding this comment

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

i allow writeAckWrapper to be nil and use chanKeeperV2 if so. cc: @srdtrk for feedback

Copy link
Member

Choose a reason for hiding this comment

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

Lets force them to pass it twice

Comment on lines +173 to +174
TimeoutHeight: clienttypes.Height{},
TimeoutTimestamp: 0,
Copy link
Member Author

Choose a reason for hiding this comment

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

timeout values zeroed out everywhere. So we preserve interface, but contracts should not rely on these values for v2 packets

TimeoutTimestamp: 0,
}
return im.contractKeeper.IBCOnAcknowledgementPacketCallback(
cachedCtx, packetv1, acknowledgement, relayer, cbData.CallbackAddress, cbData.SenderAddress, payload.Version,
Copy link
Member Author

Choose a reason for hiding this comment

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

However, here acknowledgement callback just expects []byte

Copy link
Member

Choose a reason for hiding this comment

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

This is bad because old apps won't recognize the new error ack we have, we should consider if this is ok or we need to do something about this such as passing nil if we get universal error ack

Copy link
Member Author

Choose a reason for hiding this comment

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

Indeed, discussed and the plan is to document and keep as-is for now. We will check with confio team on what they would prefer

Copy link
Contributor

@gjermundgaraba gjermundgaraba left a comment

Choose a reason for hiding this comment

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

The setup looks logical enough to me. I don't know the callbacks middleware to feel very confident without a proper walkthrough. So I guess we will do another internal audit where we can walk through this a bit more.
Until then, I want @srdtrk to do the main review of this PR.

@gjermundgaraba
Copy link
Contributor

Would also reccommend updating branch and rerunning the linter locally

Copy link
Member

@srdtrk srdtrk left a comment

Choose a reason for hiding this comment

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

Looking good. I see some issues which I mentioned

Comment on lines 159 to 207
// ProcessCallback executes the callbackExecutor and reverts contract changes if the callbackExecutor fails.
//
// Error Precedence and Returns:
// - oogErr: Takes the highest precedence. If the callback runs out of gas, an error wrapped with types.ErrCallbackOutOfGas is returned.
// - panicErr: Takes the second-highest precedence. If a panic occurs and it is not propagated, an error wrapped with types.ErrCallbackPanic is returned.
// - callbackErr: If the callbackExecutor returns an error, it is returned as-is.
//
// panics if
// - the contractExecutor panics for any reason, and the callbackType is SendPacket, or
// - the contractExecutor runs out of gas and the relayer has not reserved gas grater than or equal to
// CommitGasLimit.
func ProcessCallback(
ctx sdk.Context, callbackType CallbackType,
callbackData CallbackData, callbackExecutor func(sdk.Context) error,
) (err error) {
cachedCtx, writeFn := ctx.CacheContext()
cachedCtx = cachedCtx.WithGasMeter(storetypes.NewGasMeter(callbackData.ExecutionGasLimit))

defer func() {
// consume the minimum of g.consumed and g.limit
ctx.GasMeter().ConsumeGas(cachedCtx.GasMeter().GasConsumedToLimit(), fmt.Sprintf("ibc %s callback", callbackType))

// recover from all panics except during SendPacket callbacks
if r := recover(); r != nil {
if callbackType == CallbackTypeSendPacket {
panic(r)
}
err = errorsmod.Wrapf(ErrCallbackPanic, "ibc %s callback panicked with: %v", callbackType, r)
}

// if the callback ran out of gas and the relayer has not reserved enough gas, then revert the state
if cachedCtx.GasMeter().IsPastLimit() {
if callbackData.AllowRetry() {
panic(storetypes.ErrorOutOfGas{Descriptor: fmt.Sprintf("ibc %s callback out of gas; commitGasLimit: %d", callbackType, callbackData.CommitGasLimit)})
}
err = errorsmod.Wrapf(ErrCallbackOutOfGas, "ibc %s callback out of gas", callbackType)
}

// allow the transaction to be committed, continuing the packet lifecycle
}()

err = callbackExecutor(cachedCtx)
if err == nil {
writeFn()
}

return err
}

Copy link
Member

Choose a reason for hiding this comment

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

This probably shouldn't be part of the public API. Can we create an internal package that can be shared between v1 and v2?


return IBCMiddleware{
app: packetDataUnmarshalerApp,
writeAckWrapper: writeAckWrapper,
Copy link
Member

Choose a reason for hiding this comment

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

Lets force them to pass it twice

}
// wrap the individual acknowledgement into the channeltypesv2.Acknowledgement since it implements the exported.Acknowledgement interface
var ack channeltypesv2.Acknowledgement
if recvResult.Status == channeltypesv2.PacketStatus_Failure {
Copy link
Member

Choose a reason for hiding this comment

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

Don't we return early if this is the case anyway?? So remove the if statement and only keep the else case. We don't make callbacks if an error ack occurred

TimeoutTimestamp: 0,
}
return im.contractKeeper.IBCOnAcknowledgementPacketCallback(
cachedCtx, packetv1, acknowledgement, relayer, cbData.CallbackAddress, cbData.SenderAddress, payload.Version,
Copy link
Member

Choose a reason for hiding this comment

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

This is bad because old apps won't recognize the new error ack we have, we should consider if this is ok or we need to do something about this such as passing nil if we get universal error ack

sequence uint64,
ack channeltypesv2.Acknowledgement,
) error {
packet, found := im.chanKeeperV2.GetAsyncPacket(ctx, clientID, sequence)
Copy link
Member

Choose a reason for hiding this comment

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

Nice

Comment on lines 347 to 350
// NOTE: use first payload as the payload that is being handled by callbacks middleware
// must reconsider if multipacket data gets supported with async packets
payload := packet.Payloads[0]

Copy link
Member

Choose a reason for hiding this comment

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

somewhere before this we should assert packet.Payloads.length == 1. And link multi-payload packet tracking issue

Copy link
Member Author

Choose a reason for hiding this comment

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

good shout


// PacketDataUnmarshaler defines an optional interface which allows a middleware
// to request the packet data to be unmarshaled by the base application.
type PacketDataUnmarshaler interface {
Copy link
Member

Choose a reason for hiding this comment

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

Does this need to carry the same name as the old interface? We can call it PayloadUnmarshaler

Copy link

Copy link
Member

@srdtrk srdtrk left a comment

Choose a reason for hiding this comment

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

Let's get this merged

@AdityaSripal AdityaSripal added this pull request to the merge queue Feb 10, 2025
Merged via the queue into main with commit 5ee5783 Feb 10, 2025
68 of 69 checks passed
@AdityaSripal AdityaSripal deleted the aditya/cherrypick-callbacks-eureka branch February 10, 2025 22:44
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.

Upgrade Callbacks Middleware to Eureka
3 participants