From 3e0433eee7d0e5244f7c37f1eaa87f18c1e91c3a Mon Sep 17 00:00:00 2001 From: David Klank <155117116+davidjsonn@users.noreply.github.com> Date: Mon, 4 Aug 2025 18:11:06 +0300 Subject: [PATCH] docs: fix misspelled issues (#25080) Co-authored-by: Alex | Interchain Labs --- docs/architecture/adr-046-module-params.md | 2 +- docs/architecture/adr-047-extend-upgrade-plan.md | 4 ++-- docs/architecture/adr-050-sign-mode-textual.md | 2 +- docs/architecture/adr-054-semver-compatible-modules.md | 2 +- docs/architecture/adr-058-auto-generated-cli.md | 2 +- docs/architecture/adr-059-test-scopes.md | 2 +- docs/architecture/adr-060-abci-1.0.md | 2 +- docs/architecture/adr-063-core-module-api.md | 2 +- docs/architecture/adr-065-store-v2.md | 4 ++-- docs/architecture/adr-076-tx-malleability.md | 2 +- 10 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 11399476d8..4cc7c60267 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -162,7 +162,7 @@ module may be removed entirely in a future release. ### Negative -* Module parameters becomes slightly more burdensome for module developers: +* Module parameters become slightly more burdensome for module developers: * Modules are now responsible for persisting and retrieving parameter state * Modules are now required to have unique message handlers to handle parameter changes per unique parameter data structure. diff --git a/docs/architecture/adr-047-extend-upgrade-plan.md b/docs/architecture/adr-047-extend-upgrade-plan.md index 417e05462f..610feccc98 100644 --- a/docs/architecture/adr-047-extend-upgrade-plan.md +++ b/docs/architecture/adr-047-extend-upgrade-plan.md @@ -59,7 +59,7 @@ The current upgrade process has this timeline: We will update the `x/upgrade.Plan` message for providing upgrade instructions. The upgrade instructions will contain a list of artifacts available for each platform. It allows for the definition of a pre-run and post-run commands. -These commands are not consensus guaranteed; they will be executed by Cosmosvisor (or other) during its upgrade handling. +These commands are not consensus guaranteed; they will be executed by Cosmovisor (or other) during its upgrade handling. ```protobuf message Plan { @@ -88,7 +88,7 @@ All fields in the `UpgradeInstructions` are optional. This command MUST behave the same as the current [pre-upgrade](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) command. It does not take in any command-line arguments and is expected to terminate with the following exit codes: - | Exit status code | How it is handled in Cosmosvisor | + | Exit status code | How it is handled in Cosmovisor | |------------------|---------------------------------------------------------------------------------------------------------------------| | `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. | | `1` | Default exit code when `pre-upgrade` command has not been implemented. | diff --git a/docs/architecture/adr-050-sign-mode-textual.md b/docs/architecture/adr-050-sign-mode-textual.md index cf871bad22..a1de1acb54 100644 --- a/docs/architecture/adr-050-sign-mode-textual.md +++ b/docs/architecture/adr-050-sign-mode-textual.md @@ -226,7 +226,7 @@ Tipper: Transaction Body is the `Tx.TxBody.Messages` field, which is an array of `Any`s, where each `Any` packs a `sdk.Msg`. Since `sdk.Msg`s are widely used, they have a slightly different encoding than usual array of `Any`s (Protobuf: `repeated google.protobuf.Any`) described in Annex 1. ``` -This transaction has message: // Optional 's' for "message" if there's is >1 sdk.Msgs. +This transaction has message: // Optional 's' for "message" if there's >1 sdk.Msgs. // For each Msg, print the following 2 lines: Msg (/): // E.g. Msg (1/2): bank v1beta1 send coins diff --git a/docs/architecture/adr-054-semver-compatible-modules.md b/docs/architecture/adr-054-semver-compatible-modules.md index d2b5d25801..7f6c28f0dc 100644 --- a/docs/architecture/adr-054-semver-compatible-modules.md +++ b/docs/architecture/adr-054-semver-compatible-modules.md @@ -471,7 +471,7 @@ to `cosmossdk.io/core/intermodule.Client`: ServiceRevision(ctx context.Context, serviceName string) uint64 ``` -Modules could all this using the service name statically generated by the go grpc code generator: +Modules could call this using the service name statically generated by the go grpc code generator: ```go intermoduleClient.ServiceRevision(ctx, bankv1beta1.Msg_ServiceDesc.ServiceName) diff --git a/docs/architecture/adr-058-auto-generated-cli.md b/docs/architecture/adr-058-auto-generated-cli.md index b295ff4b26..8dc78920a2 100644 --- a/docs/architecture/adr-058-auto-generated-cli.md +++ b/docs/architecture/adr-058-auto-generated-cli.md @@ -81,7 +81,7 @@ We would like to be able to customize: * which fields are positional parameters rather than flags It is an [open discussion](https://github.com/cosmos/cosmos-sdk/pull/11725#issuecomment-1108676129) -as to whether these customizations options should line in: +as to whether these customizations options should lie in: * the .proto files themselves, * separate config files (ex. YAML), or diff --git a/docs/architecture/adr-059-test-scopes.md b/docs/architecture/adr-059-test-scopes.md index 99529d180d..6fa387c20e 100644 --- a/docs/architecture/adr-059-test-scopes.md +++ b/docs/architecture/adr-059-test-scopes.md @@ -153,7 +153,7 @@ The SDK uses an application will only the required modules for the tests. The ap #### Limitations In general the limitations of end to end tests are orchestration and compute cost. -Scaffolding is required to start up and run a prod-like environment and the this +Scaffolding is required to start up and run a prod-like environment and this process takes much longer to start and run than unit or integration tests. Global locks present in Tendermint code cause stateful starting/stopping to sometimes hang diff --git a/docs/architecture/adr-060-abci-1.0.md b/docs/architecture/adr-060-abci-1.0.md index d2d93a89e2..41e2230bc3 100644 --- a/docs/architecture/adr-060-abci-1.0.md +++ b/docs/architecture/adr-060-abci-1.0.md @@ -84,7 +84,7 @@ type Mempool interface { // Select returns an Iterator over the app-side mempool. If txs are specified, // then they shall be incorporated into the Iterator. The Iterator must - // closed by the caller. + // be closed by the caller. Select(sdk.Context, [][]byte) Iterator // CountTx returns the number of transactions currently in the mempool. diff --git a/docs/architecture/adr-063-core-module-api.md b/docs/architecture/adr-063-core-module-api.md index 3605dc52e0..cb5bb02b3b 100644 --- a/docs/architecture/adr-063-core-module-api.md +++ b/docs/architecture/adr-063-core-module-api.md @@ -282,7 +282,7 @@ type HasGenesis interface { #### Pre Blockers -Modules that have functionality that runs before BeginBlock and should implement the has `HasPreBlocker` interfaces: +Modules that have functionality that runs before BeginBlock and should implement the `HasPreBlocker` interfaces: ```go type HasPreBlocker interface { diff --git a/docs/architecture/adr-065-store-v2.md b/docs/architecture/adr-065-store-v2.md index 8faed0463d..f8cb0bbe83 100644 --- a/docs/architecture/adr-065-store-v2.md +++ b/docs/architecture/adr-065-store-v2.md @@ -35,7 +35,7 @@ application state. This data structure is the base layer `KVStore`. In addition, the SDK provides abstractions on top of this Merkle data structure. Namely, a root multi-store (RMS) is a collection of each module's `KVStore`. Through the RMS, the application can serve queries and provide proofs to clients -in addition to provide a module access to its own unique `KVStore` though the use +in addition to provide a module access to its own unique `KVStore` through the use of `StoreKey`, which is an OCAP primitive. There are further layers of abstraction that sit between the RMS and the underlying @@ -65,7 +65,7 @@ See the [Storage Discussion](https://github.com/cosmos/cosmos-sdk/discussions/13 ## Alternatives There was a previous attempt to refactor the storage layer described in [ADR-040](./adr-040-storage-and-smt-state-commitments.md). -However, this approach mainly stems on the short comings of IAVL and various performance +However, this approach mainly stems on the shortcomings of IAVL and various performance issues around it. While there was a (partial) implementation of [ADR-040](./adr-040-storage-and-smt-state-commitments.md), it was never adopted for a variety of reasons, such as the reliance on using an SMT, which was more in a research phase, and some design choices that couldn't diff --git a/docs/architecture/adr-076-tx-malleability.md b/docs/architecture/adr-076-tx-malleability.md index d947dbc705..cb8d121d39 100644 --- a/docs/architecture/adr-076-tx-malleability.md +++ b/docs/architecture/adr-076-tx-malleability.md @@ -128,7 +128,7 @@ Unfortunately, the vast majority of unaddressed malleability risks affect `SIGN_ sign mode is still commonly used. It is recommended that the following improvements be made to Amino JSON signing: -* hashes of `TxBody` and `AuthInfo` should be added to `AminoSignDoc` so that encoding-level malleablity is addressed +* hashes of `TxBody` and `AuthInfo` should be added to `AminoSignDoc` so that encoding-level malleability is addressed * when constructing `AminoSignDoc`, [protoreflect](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect) API should be used to ensure that there no fields in `TxBody` or `AuthInfo` which do not have a mapping in `AminoSignDoc` have been set * fields present in `TxBody` or `AuthInfo` that are not present in `AminoSignDoc` (such as extension options) should be added to `AminoSignDoc` if possible