IBC Client event for client UpgradeProposal

[ancazamfir]

Summary

hermes has a CLI for client UpgradeProposal. Currently, in order to determine if an upgrade proposal was successful, hermes needs to dig out for some non-IBC events (i.e. not defined in events.md).

Problem Definition

Proposal

The proto message for a client upgrade proposal is defined in

ibc-go/proto/ibc/core/client/v1/client.proto

Line 58 in 9680cb9

message UpgradeProposal {

.

Could we have an IBC event emitted (something like EmitUpgradeProposalEvent) in:

ibc-go/modules/core/02-client/keeper/proposal.go

Line 82 in 9680cb9

func (k Keeper) HandleUpgradeProposal(ctx sdk.Context, p *types.UpgradeProposal) error {

and documented in events.md

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

Hi @ancazamfir. Would including the plan height and the title in the event enough information for your needs?

I am thinking of emitting the event only in the case where the upgraded client is successfully set in the upgrade store, so to replace this line with this:

err = k.upgradeKeeper.SetUpgradedClient(ctx, p.Plan.Height, bz)

if err != nil {
  ctx.EventManager().EmitEvent(
    sdk.NewEvent(
      types.EventTypeUpgradeClientProposal,
      sdk.NewAttribute(types.AttributeKeyUpgradePlanTitle, p.Title),
      sdk.NewAttribute(types.AttributeKeyUpgradePlanHeight, strconv.FormatInt(p.Plan.Height, 10)),
    ),
  )
}

return err

Would this work for you? Do you need any more information in the event?

[ancazamfir]

Would including the plan height and the title in the event enough information for your needs?

I think so. Currently not implemented but we are considering starting a relayer "worker" on this event, get the height and wait for the chain to reach the proposal height. At that point it would (attempt to) upgrade its clients on other chains. I assume that if we are able to query the upgraded client and consensus states it means that the plan was approved. In other words we won't have to also query the plan status (passed vs rejected) so we don't need the proposal_id.