chore: fixes from diff review (#24595)

aljo242 · web-flow · commit 36e90bb980f0 · 2025-04-28T22:38:57.000Z
diff --git a/depinject/README.md b/depinject/README.md
@@ -75,7 +75,7 @@ Provider functions serve as the basis for the dependency tree. They are analysed
 
 `depinject` supports the use of interface types as inputs to provider functions, which helps decouple dependencies between modules. This approach is particularly useful for managing complex systems with multiple modules, such as the Cosmos SDK, where dependencies need to be flexible and maintainable.
 
-For example, `x/bank` expects an [AccountKeeper](https://pkg.go.dev/cosmossdk.io/x/bank/types#AccountKeeper) interface as [input to ProvideModule](https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/bank/module.go#L208-L260). `SimApp` uses the implementation in `x/auth`, but the modular design allows for easy changes to the implementation if needed.
+For example, `x/bank` expects an [AccountKeeper](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/x/bank/types#AccountKeeper) interface as [input to ProvideModule](https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/bank/module.go#L208-L260). `SimApp` uses the implementation in `x/auth`, but the modular design allows for easy changes to the implementation if needed.
 
 Consider the following example:
 
@@ -177,7 +177,7 @@ When using `depinject.Inject`, the injected types must be pointers.
 :::
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.2/simapp/app_di.go#L187-L206
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_di.go#L165-L188
 ```
 
 ## Debugging
diff --git a/docs/.gitignore b/docs/.gitignore
@@ -21,7 +21,6 @@ docs/docs/tooling/03-hubl.md
 docs/docs/core/17-autocli.md
 docs/docs/packages/01-depinject.md
 docs/docs/packages/02-collections.md
-docs/user/run-node/04-rosetta.md
 docs/build/migrations/02-upgrading.md
 docs/learn/advanced/17-autocli.md
 
diff --git a/docs/architecture/adr-057-app-wiring.md b/docs/architecture/adr-057-app-wiring.md
@@ -306,13 +306,13 @@ change to a module should be handled as follows:
 - the semantic major version should be incremented, and
 - a new semantically versioned module config protobuf type should be created.
 
-For instance, if we have the SDK module for bank in the go module `cosmossdk.io/x/bank` with the module config type
+For instance, if we have the SDK module for bank in the go module `github.com/cosmos/cosmos-sdk/x/bank` with the module config type
 `cosmos.bank.module.v1.Module`, and we want to make a state machine breaking change to the module, we would:
-- create a new go module `cosmossdk.io/x/bank/v2`,
+- create a new go module `github.com/cosmos/cosmos-sdk/x/bank/v2`,
 - with the module config protobuf type `cosmos.bank.module.v2.Module`.
 
 This _does not_ mean that we need to increment the protobuf API version for bank. Both modules can support
-`cosmos.bank.v1`, but `cosmossdk.io/x/bank/v2` will be a separate go module with a separate module config type.
+`cosmos.bank.v1`, but `github.com/cosmos/cosmos-sdk/x/bank/v2` will be a separate go module with a separate module config type.
 
 This practice will eventually allow us to use appconfig to load new versions of a module via a configuration change.
 
diff --git a/docs/docs/build/building-modules/15-depinject.md b/docs/docs/build/building-modules/15-depinject.md
@@ -121,4 +121,4 @@ The module is now ready to be used with `depinject` by a chain developer.
 
 ## Integrate in an application
 
-The App Wiring is done in `app_config.go` / `app.yaml` and `app_v2.go` and is explained in detail in the [overview of `app_v2.go`](../building-apps/01-app-go-di.md).
+The App Wiring is done in `app_config.go` / `app.yaml` and `app_di.go` and is explained in detail in the [overview of `app_di.go`](../building-apps/01-app-go-di.md).
diff --git a/docs/docs/build/tooling/README.md b/docs/docs/build/tooling/README.md
@@ -11,7 +11,6 @@ This includes tools for development, operating a node, and ease of use of a Cosm
 
 * [Cosmovisor](./01-cosmovisor.md)
 * [Confix](./02-confix.md)
-* [Rosetta](https://docs.cosmos.network/main/run-node/rosetta)
 
 ## Other Tools
 
diff --git a/docs/docs/learn/advanced/12-simulation.md b/docs/docs/learn/advanced/12-simulation.md
@@ -35,9 +35,7 @@ failure type:
   inconsistencies between the stores.
 * `AppSimulationAfterImport`: Queues two simulations together. The first one provides the app state (_i.e_ genesis) to the second. Useful to test software upgrades or hard-forks from a live chain.
 * `AppStateDeterminism`: Checks that all the nodes return the same values, in the same order.
-* `BenchmarkInvariants`: Analysis of the performance of running all modules' invariants (_i.e_ sequentially runs a [benchmark](https://pkg.go.dev/testing/#hdr-Benchmarks) test). An invariant checks for
-  differences between the values that are on the store and the passive tracker. Eg: total coins held by accounts vs total supply tracker.
-* `FullAppSimulation`: General simulation mode. Runs the chain and the specified operations for a given number of blocks. Tests that there're no `panics` on the simulation. It does also run invariant checks on every `Period` but they are not benchmarked.
+* `FullAppSimulation`: General simulation mode. Runs the chain and the specified operations for a given number of blocks. Tests that there're no `panics` on the simulation.
 
 Each simulation must receive a set of inputs (_i.e_ flags) such as the number of
 blocks that the simulation is run, seed, block size, etc.
@@ -80,15 +78,10 @@ Here are some suggestions when encountering a simulation failure:
   by passing the `-ExportStatePath` flag to the simulator.
 * Use `-Verbose` logs. They could give you a better hint on all the operations
   involved.
-* Reduce the simulation `-Period`. This will run the invariants checks more
-  frequently.
-* Print all the failed invariants at once with `-PrintAllInvariants`.
 * Try using another `-Seed`. If it can reproduce the same error and if it fails
   sooner, you will spend less time running the simulations.
 * Reduce the `-NumBlocks` . How's the app state at the height previous to the
   failure?
-* Run invariants on every operation with `-SimulateEveryOperation`. _Note_: this
-  will slow down your simulation **a lot**.
 * Try adding logs to operations that are not logged. You will have to define a
   [Logger](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/x/staking/keeper/keeper.go#L77-L81) on your `Keeper`.
 
diff --git a/docs/post.sh b/docs/post.sh
@@ -7,7 +7,6 @@ rm -rf docs/build/tooling/03-hubl.md
 rm -rf docs/build/packages/01-depinject.md
 rm -rf docs/build/packages/02-collections.md
 rm -rf docs/learn/advaced-concepts/17-autocli.md
-rm -rf docs/user/run-node/04-rosetta.md
 rm -rf docs/build/architecture
 rm -rf docs/build/spec
 rm -rf docs/build/rfc
diff --git a/docs/pre.sh b/docs/pre.sh
@@ -25,7 +25,6 @@ cat ../x/README.md | sed 's/\.\.\/docs\/build\/building-modules\/README\.md/\/bu
 ## Add tooling documentation
 cp ../tools/cosmovisor/README.md ./docs/build/tooling/01-cosmovisor.md
 cp ../tools/confix/README.md ./docs/build/tooling/02-confix.md
-wget -O docs/user/run-node/04-rosetta.md https://raw.githubusercontent.com/cosmos/rosetta/main/README.md
 
 ## Add package documentation
 cp ../client/v2/README.md ./docs/learn/advanced/17-autocli.md
diff --git a/math/sonar-project.properties b/math/sonar-project.properties
diff --git a/store/go.mod b/store/go.mod
@@ -8,6 +8,7 @@ require (
 	cosmossdk.io/math v1.5.3
 	github.com/cometbft/cometbft v0.38.17
 	github.com/cosmos/cosmos-db v1.1.1
+	github.com/cosmos/cosmos-proto v1.0.0-beta.5
 	github.com/cosmos/gogoproto v1.7.0
 	github.com/cosmos/iavl v1.2.0
 	github.com/cosmos/ics23/go v0.11.0
@@ -26,8 +27,6 @@ require (
 	gotest.tools/v3 v3.5.2
 )
 
-require github.com/cosmos/cosmos-proto v1.0.0-beta.5
-
 require (
 	github.com/DataDog/zstd v1.5.6 // indirect
 	github.com/beorn7/perks v1.0.1 // indirect

Original file line number	Diff line number	Diff line change
@@ -121,4 +121,4 @@ The module is now ready to be used with `depinject` by a chain developer.
`121`	`121`
`122`	`122`	`## Integrate in an application`
`123`	`123`
`124`		-The App Wiring is done in `app_config.go` / `app.yaml` and `app_v2.go` and is explained in detail in the [overview of `app_v2.go`](../building-apps/01-app-go-di.md).
	`124`	+The App Wiring is done in `app_config.go` / `app.yaml` and `app_di.go` and is explained in detail in the [overview of `app_di.go`](../building-apps/01-app-go-di.md).