From 8918fe28c89631655de1f562b7a6bfbb2d9e91ce Mon Sep 17 00:00:00 2001 From: sashass1315 Date: Wed, 30 Jul 2025 17:34:23 +0300 Subject: [PATCH] docs: fix broken links across documentation (#25052) --- docs/architecture/adr-033-protobuf-inter-module-comm.md | 2 +- docs/architecture/adr-063-core-module-api.md | 2 +- docs/docs/build/building-modules/01-module-manager.md | 2 +- docs/docs/build/building-modules/09-module-interfaces.md | 4 ++-- docs/docs/learn/advanced/06-grpc_rest.md | 2 +- docs/docs/learn/advanced/15-upgrade.md | 2 +- docs/docs/learn/beginner/02-query-lifecycle.md | 8 ++++---- store/snapshots/README.md | 4 ++-- x/authz/README.md | 2 +- 9 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/architecture/adr-033-protobuf-inter-module-comm.md b/docs/architecture/adr-033-protobuf-inter-module-comm.md index 9f05ec6535..49126f0ef8 100644 --- a/docs/architecture/adr-033-protobuf-inter-module-comm.md +++ b/docs/architecture/adr-033-protobuf-inter-module-comm.md @@ -20,7 +20,7 @@ service definitions defined in [ADR 021](./adr-021-protobuf-query-encoding.md) a ## Context -In the current Cosmos SDK documentation on the [Object-Capability Model](../../learn/advanced/10-ocap.md), it is stated that: +In the current Cosmos SDK documentation on the [Object-Capability Model](../../docs/learn/advanced/10-ocap.md), it is stated that: > We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. diff --git a/docs/architecture/adr-063-core-module-api.md b/docs/architecture/adr-063-core-module-api.md index bf3940b36d..b727530b1e 100644 --- a/docs/architecture/adr-063-core-module-api.md +++ b/docs/architecture/adr-063-core-module-api.md @@ -388,7 +388,7 @@ Additional `AppModule` extension interfaces either inside or outside of core wil these concerns. In the case of gogo proto and amino interfaces, the registration of these generally should happen as early -as possible during initialization and in [ADR 057: App Wiring](./adr-057-app-wiring-1.md), protobuf type registration +as possible during initialization and in [ADR 057: App Wiring](./adr-057-app-wiring.md), protobuf type registration happens before dependency injection (although this could alternatively be done dedicated DI providers). gRPC gateway registration should probably be handled by the runtime module, but the core API shouldn't depend on gRPC diff --git a/docs/docs/build/building-modules/01-module-manager.md b/docs/docs/build/building-modules/01-module-manager.md index 7dfc7545c8..89737cbf22 100644 --- a/docs/docs/build/building-modules/01-module-manager.md +++ b/docs/docs/build/building-modules/01-module-manager.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Module Manager :::note Synopsis -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../../learn/advanced/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](../../learn/beginner/00-app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](../../learn/beginner/00-app-anatomy.md#begingblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../../learn/advanced/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](../../learn/beginner/00-app-anatomy.md#preblocker) and [`BeginBlocker` and `EndBlocker`](../../learn/beginner/00-app-anatomy.md#begingblocker-and-endblocker). ::: :::note Pre-requisite Readings diff --git a/docs/docs/build/building-modules/09-module-interfaces.md b/docs/docs/build/building-modules/09-module-interfaces.md index 4552baef24..432ecf910d 100644 --- a/docs/docs/build/building-modules/09-module-interfaces.md +++ b/docs/docs/build/building-modules/09-module-interfaces.md @@ -159,6 +159,6 @@ Modules that want to expose REST queries should add `google.api.http` annotation https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/auth/v1beta1/query.proto#L14-L89 ``` -gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml). +gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../../user/run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml). -The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered. +The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../../user/run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered. diff --git a/docs/docs/learn/advanced/06-grpc_rest.md b/docs/docs/learn/advanced/06-grpc_rest.md index e10bda099c..d3ab827a79 100644 --- a/docs/docs/learn/advanced/06-grpc_rest.md +++ b/docs/docs/learn/advanced/06-grpc_rest.md @@ -26,7 +26,7 @@ All endpoints are defaulted to localhost and must be modified to be exposed to t ## gRPC Server -In the Cosmos SDK, Protobuf is the main [encoding](./encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. +In the Cosmos SDK, Protobuf is the main [encoding](./05-encoding.md) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. Each module exposes a [Protobuf `Query` service](../../build/building-modules/02-messages-and-queries.md#queries) that defines state queries. The `Query` services and a transaction service used to broadcast transactions are hooked up to the gRPC server via the following function inside the application: diff --git a/docs/docs/learn/advanced/15-upgrade.md b/docs/docs/learn/advanced/15-upgrade.md index 55cd8b0525..e2332bd1ca 100644 --- a/docs/docs/learn/advanced/15-upgrade.md +++ b/docs/docs/learn/advanced/15-upgrade.md @@ -159,4 +159,4 @@ You can sync a full node to an existing blockchain which has been upgraded using To successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction, then you can run Cosmovisor with auto-download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise, you need to manually provide all binaries to Cosmovisor. -To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../../build/tooling/01-cosmovisor.md). +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../../../../tools/cosmovisor/README.md). diff --git a/docs/docs/learn/beginner/02-query-lifecycle.md b/docs/docs/learn/beginner/02-query-lifecycle.md index 4994da6071..9a28dc5df4 100644 --- a/docs/docs/learn/beginner/02-query-lifecycle.md +++ b/docs/docs/learn/beginner/02-query-lifecycle.md @@ -17,7 +17,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr A [**query**](../../build/building-modules/02-messages-and-queries.md#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](../advanced/01-transactions.md) (view the lifecycle [here](./01-tx-lifecycle.md)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](../../build/modules/staking/README.md) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](../../../../x/staking/README.md) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -27,7 +27,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](../../build/modules/staking/README.md) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](../../../../x/staking/README.md) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: @@ -74,9 +74,9 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](../advanced/05-encoding.md) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](../../build/modules/auth/README.md) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](../../../../x/auth/README.md) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. -* **Keyring**: A [Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. +* **Keyring**: A [Key Manager](../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. * **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query, and `--indent`, which indicates to add an indent to the JSON response. diff --git a/store/snapshots/README.md b/store/snapshots/README.md index b98a2547fa..c50c438a70 100644 --- a/store/snapshots/README.md +++ b/store/snapshots/README.md @@ -11,8 +11,8 @@ This document describes the Cosmos SDK implementation of the ABCI state sync interface, for more information on CometBFT state sync in general see: * [CometBFT State Sync for Developers](https://medium.com/cometbft/cometbft-core-state-sync-for-developers-70a96ba3ee35) -* [ABCI State Sync Spec](https://docs.cometbft.com/v0.37/spec/p2p/messages/state-sync) -* [ABCI State Sync Method/Type Reference](https://docs.cometbft.com/v0.37/spec/p2p/messages/state-sync) +* [ABCI State Sync Spec](https://docs.cometbft.com/v0.37/spec/p2p/legacy-docs/messages/state-sync) +* [ABCI State Sync Method/Type Reference](https://docs.cometbft.com/v0.37/spec/p2p/legacy-docs/messages/state-sync) ## Overview diff --git a/x/authz/README.md b/x/authz/README.md index 9ce112cc50..41cfccc628 100644 --- a/x/authz/README.md +++ b/x/authz/README.md @@ -38,7 +38,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](../modules/auth/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](../auth/) module that is responsible for specifying the base transaction and account types. ```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/authz/authorizations.go#L11-L25