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

feat: migrate x/capability to app wiring #12058

Merged
merged 26 commits into from
Jun 2, 2022
Merged

Conversation

facundomedica
Copy link
Member

@facundomedica facundomedica commented May 26, 2022

Description

Migrate x/capability to the new app wiring (dependency injection).

Tracking progress at #12069


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@@ -216,6 +216,9 @@ func (app *BaseApp) MountStores(keys ...storetypes.StoreKey) {
case *storetypes.TransientStoreKey:
app.MountStore(key, storetypes.StoreTypeTransient)

case *storetypes.MemoryStoreKey:
Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure if adding this to baseapp is the way to go

Copy link
Contributor

Choose a reason for hiding this comment

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

What's the context here?

Copy link
Member Author

Choose a reason for hiding this comment

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

runtime/builder uses baseApps' MountStores. Without this addition we get this error Unrecognized store key type :*types.MemoryStoreKey.
I think that if we filter out any MemoryStoreKeys before calling this everything works just fine... I don't know enough about these things to know exactly what's up 😅

// Build builds an *App instance.
func (a *AppBuilder) Build(logger log.Logger, db dbm.DB, traceStore io.Writer, baseAppOptions ...func(*baseapp.BaseApp)) *App {
for _, option := range a.app.baseAppOptions {
baseAppOptions = append(baseAppOptions, option)
}
// TODO: when the auth module is configured, fill-in txDecoder
bApp := baseapp.NewBaseApp(a.app.config.AppName, logger, db, nil, baseAppOptions...)
bApp.SetCommitMultiStoreTracer(traceStore)
bApp.SetVersion(version.Version)
bApp.SetInterfaceRegistry(a.app.interfaceRegistry)
bApp.MountStores(a.app.storeKeys...)
a.app.BaseApp = bApp
return a.app
}

Copy link
Member Author

Choose a reason for hiding this comment

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

nvm tried again removing it and it doesn't work

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not really sure about this code. I'd have to delegate to @aaronc here.

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 addition is correct. IMHO the fact that the multi-store doesn't know how to map store keys -> store types is a really strange and error prone. So this patch is sort of needed, but really the multi-store design should be cleaned up a bit

@@ -14,7 +14,7 @@ const (
StoreKey = ModuleName

// MemStoreKey defines the in-memory store key
MemStoreKey = "mem_capability"
MemStoreKey = "memory:capability"
Copy link
Member Author

Choose a reason for hiding this comment

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

This is only used for testing, we might want to move it over. Same goes for StoreKey.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why was this change necessary, just curious?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because now the store keys are being registered through this function that has a fixed format:

func provideMemoryStoreKey(key container.ModuleKey, app appWrapper) *storetypes.MemoryStoreKey {
storeKey := storetypes.NewMemoryStoreKey(fmt.Sprintf("memory:%s", key.Name()))
registerStoreKey(app, storeKey)
return storeKey
}

I think this key is now deprecated and used only in tests because we don't use it anywhere else.

Copy link
Contributor

Choose a reason for hiding this comment

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

got it. If so, can we prefix the variable with Test or something? Or maybe just remove it completely and define it directly in tests?

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 think we should move it over to test. We still need it to create the MemoryStoreKey pass it to the Keeper in tests. @aaronc this is what I pinged you about on Slack

Copy link
Contributor

Choose a reason for hiding this comment

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

We should maybe even have a copy of simapp/app.go before the app wiring (maybe simapp/legacy) that checks to make sure that way still works

I like that idea!

Copy link
Member Author

@facundomedica facundomedica May 27, 2022

Choose a reason for hiding this comment

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

Ok, just opened #12068 to track that

Copy link
Member Author

Choose a reason for hiding this comment

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

And I will go back to MemStoreKey = "mem_capability" and create a new constant in the tests

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 it's okay to change the value of MemStoreKey just not to delete the const

Copy link
Member Author

Choose a reason for hiding this comment

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

Gotcha, will revert that last change then 👌

simapp/app.go Outdated Show resolved Hide resolved
simapp/app.go Outdated Show resolved Hide resolved
@facundomedica
Copy link
Member Author

All tests passing 🎉

@facundomedica facundomedica marked this pull request as ready for review May 26, 2022 20:57
@facundomedica facundomedica requested a review from a team as a code owner May 26, 2022 20:57
return msk
}

sk := app.UnsafeFindStoreKey(storeKey)
Copy link
Contributor

Choose a reason for hiding this comment

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

When would a mem key be found in the list of real store keys?

Copy link
Member Author

Choose a reason for hiding this comment

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

provideMemoryStoreKey calls registerStoreKey which appends the key to the list of store keys. Should we have a separate list for them?

func provideMemoryStoreKey(key container.ModuleKey, app appWrapper) *storetypes.MemoryStoreKey {
storeKey := storetypes.NewMemoryStoreKey(fmt.Sprintf("memory:%s", key.Name()))
registerStoreKey(app, storeKey)
return storeKey
}

@@ -216,6 +216,9 @@ func (app *BaseApp) MountStores(keys ...storetypes.StoreKey) {
case *storetypes.TransientStoreKey:
app.MountStore(key, storetypes.StoreTypeTransient)

case *storetypes.MemoryStoreKey:
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the context here?

@@ -14,7 +14,7 @@ const (
StoreKey = ModuleName

// MemStoreKey defines the in-memory store key
MemStoreKey = "mem_capability"
MemStoreKey = "memory:capability"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why was this change necessary, just curious?

simapp/app.go Outdated Show resolved Hide resolved
simapp/app.go Outdated Show resolved Hide resolved
@facundomedica facundomedica requested a review from aaronc June 1, 2022 17:42
@aaronc aaronc requested a review from kocubinski June 1, 2022 19:51
@blushi
Copy link
Contributor

blushi commented Jun 2, 2022

@facundomedica could you fix the conflicts?

defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), telemetry.MetricKeyBeginBlocker)

am.keeper.InitMemStore(ctx)

if am.sealKeeper && !am.keeper.IsSealed() {

Check warning

Code scanning / CodeQL

Panic in BeginBock or EndBlock consensus methods

Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain halt
defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), telemetry.MetricKeyBeginBlocker)

am.keeper.InitMemStore(ctx)

if am.sealKeeper && !am.keeper.IsSealed() {
am.keeper.Seal()

Check warning

Code scanning / CodeQL

Panic in BeginBock or EndBlock consensus methods

Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain halt
protoiface "google.golang.org/protobuf/runtime/protoiface"
protoimpl "google.golang.org/protobuf/runtime/protoimpl"
io "io"
reflect "reflect"

Check notice

Code scanning / CodeQL

Sensitive package import

Certain system packages contain functions which may be a possible source of non-determinism
@facundomedica facundomedica merged commit 17232fa into main Jun 2, 2022
@facundomedica facundomedica deleted the facu/app-wiring-capability branch June 2, 2022 16:53
larry0x pushed a commit to larry0x/cosmos-sdk that referenced this pull request May 22, 2023
* feat: migrate x/capability to app wiring

* added some fixes from Matt's PR + changed MemStoreKey

* fix name

* fix name

* small change

* rollback MemStoreKey change

* Revert "rollback MemStoreKey change"

This reverts commit ad191ea.

* add suggestions by @aaronc

* add IsSealed()

* fix

Co-authored-by: Aaron Craelius <aaron@regen.network>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

6 participants