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

Emit event upon setting upgrade consensus state #1741

Conversation

chatton
Copy link
Contributor

@chatton chatton commented Jul 20, 2022

Description

This PR updates BeginBlocker to update an upgrade_chain event.

closes: #270


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

Copy link
Contributor

@crodriguezvega crodriguezvega left a comment

Choose a reason for hiding this comment

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

Thanks, @chatton!

ctx.EventManager().EmitEvents(sdk.Events{
sdk.NewEvent(
types.EventTypeUpgradeChain,
sdk.NewAttribute(types.AttributeKeyUpgradePlanHeight, strconv.Itoa(int(height))),
Copy link
Contributor

Choose a reason for hiding this comment

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

In this PR Fede recommended to use strconv.FormatUint for converting uint64 to string. Could we not use strconv.FormatInt instead here? It's not like I have a strong opinion for using one or the other way, but I guess it would be nice to settle in one (if possible) and use that always. :)

Copy link
Contributor Author

@chatton chatton Jul 26, 2022

Choose a reason for hiding this comment

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

The type is int64 rather than uint64 but there is also a strconv.FormatInt(height, 10) we can use instead!

Copy link
Member

@damiannolan damiannolan left a comment

Choose a reason for hiding this comment

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

LGTM! Nice work 🚀

Comment on lines 7 to 12
sdk "github.com/cosmos/cosmos-sdk/types"
"github.com/stretchr/testify/suite"
abci "github.com/tendermint/tendermint/abci/types"
tmproto "github.com/tendermint/tendermint/proto/tendermint/types"

upgradetypes "github.com/cosmos/cosmos-sdk/x/upgrade/types"
Copy link
Member

Choose a reason for hiding this comment

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

nit: should we group upgradetypes with the above?

@@ -74,3 +77,55 @@ func (suite *ClientTestSuite) TestBeginBlockerConsensusState() {
suite.Require().NoError(err)
suite.Require().Equal(bz, consState)
}

func (suite *ClientTestSuite) TestBeginBlockerWithUpgradePlan_EmitsUpgradeChainEvent() {
Copy link
Member

Choose a reason for hiding this comment

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

nit: I don't think underscores in test names are convention in Go, right?
Could use TestBeginBlockerUpgradeEvents and TestBeginBlockerUpgradeEventsAbsence?

But I mean its probably fine to be honest, the names are meaningful as is!

Copy link
Contributor Author

@chatton chatton Jul 27, 2022

Choose a reason for hiding this comment

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

yeah no harm simplifying the name a bit, great suggestion!

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.

Nice work!

@chatton chatton merged commit d8ac28a into 02-client-refactor Jul 27, 2022
@chatton chatton deleted the cian/issue#270-emit-event-upon-setting-upgrade-consensus-state-2 branch July 27, 2022 09:50
Comment on lines +99 to +104
cacheCtx, writeCache := suite.chainA.GetContext().CacheContext()

client.BeginBlocker(cacheCtx, suite.chainA.App.GetIBCKeeper().ClientKeeper)
writeCache()

suite.requireContainsEvent(cacheCtx.EventManager().Events(), types.EventTypeUpgradeChain, true)
Copy link
Contributor

Choose a reason for hiding this comment

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

just as a note, the caching of the context should be unnecessary in this situation. You should be able to get the event via suite.chainA.GetContext() after calling begin blocker on that context

crodriguezvega pushed a commit that referenced this pull request Jul 28, 2022
oshorefueled pushed a commit to ComposableFi/ibc-go that referenced this pull request Aug 9, 2022
@crodriguezvega crodriguezvega deleted the cian/issue#270-emit-event-upon-setting-upgrade-consensus-state-2 branch February 9, 2023 12:19
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.

5 participants