docs: Remove deprecated "Interfaces" section (#8294)
* Remove useless files, add app.toml section * Rework docs * Delete interfaces * add correct next section references * Finish CLI * Small tweaks query * Add simulation docs to core * Add gRPC and REST * Finish queyr lifecycle * Updat examples * Remove prereq * fix links in simulation * Use same enumeration in md Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This commit is contained in:
Amaury
mergify[bot]
+13
-11
@@ -9,17 +9,19 @@ parent:
|
||||
This repository contains reference documentation on the core concepts of the Cosmos SDK.
|
||||
|
||||
1. [`BaseApp`](./baseapp.md)
|
||||
2. [Transaction](./transactions.md)
|
||||
3. [Context](./context.md)
|
||||
4. [Node Client](./node.md)
|
||||
5. [Store](./store.md)
|
||||
6. [Encoding](./encoding.md)
|
||||
7. [gRPC, REST and Tendermint Endpoints](./grpc_rest.md)
|
||||
8. [Events](./events.md)
|
||||
9. [Telemetry](./telemetry.md)
|
||||
10. [Object-Capabilities](./ocap.md)
|
||||
11. [RunTx recovery middleware](./runtx_middleware.md)
|
||||
12. [Protobuf documentation](./proto-docs.md)
|
||||
1. [Transaction](./transactions.md)
|
||||
1. [Context](./context.md)
|
||||
1. [Node Client](./node.md)
|
||||
1. [Store](./store.md)
|
||||
1. [Encoding](./encoding.md)
|
||||
1. [gRPC, REST and Tendermint Endpoints](./grpc_rest.md)
|
||||
1. [Command-Line Interface](./cli.md)
|
||||
1. [Events](./events.md)
|
||||
1. [Telemetry](./telemetry.md)
|
||||
1. [Object-Capabilities](./ocap.md)
|
||||
1. [RunTx recovery middleware](./runtx_middleware.md)
|
||||
1. [Simulation](./simulation.md)
|
||||
1. [Protobuf documentation](./proto-docs.md)
|
||||
|
||||
After reading about the core concepts, check the [IBC documentation](../ibc/README.md) to learn more
|
||||
about the IBC core concepts and how to integrate it to you application.
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
<!--
|
||||
order: 8
|
||||
-->
|
||||
|
||||
# Command-Line Interface
|
||||
|
||||
This document describes how commmand-line interface (CLI) works on a high-level, for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](../building-modules/module-interfaces.md#cli). {synopsis}
|
||||
|
||||
## Command-Line Interface
|
||||
|
||||
### Example Command
|
||||
|
||||
There is no set way to create a CLI, but SDK modules typically use the [Cobra Library](https://github.com/spf13/cobra). Building a CLI with Cobra entails defining commands, arguments, and flags. [**Commands**](#commands) understand the actions users wish to take, such as `tx` for creating a transaction and `query` for querying the application. Each command can also have nested subcommands, necessary for naming the specific transaction type. Users also supply **Arguments**, such as account numbers to send coins to, and [**Flags**](#flags) to modify various aspects of the commands, such as gas prices or which node to broadcast to.
|
||||
|
||||
Here is an example of a command a user might enter to interact with the simapp CLI `simd` in order to send some tokens:
|
||||
|
||||
```bash
|
||||
simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --gas auto --gas-prices <gasPrices>
|
||||
```
|
||||
|
||||
The first four strings specify the command:
|
||||
|
||||
- The root command for the entire application `simd`.
|
||||
- The subcommand `tx`, which contains all commands that let users create transactions.
|
||||
- The subcommand `bank` to indicate which module to route the command to ([`x/bank`](../../x/bank/spec/README.md) module in this case).
|
||||
- The type of transaction `send`.
|
||||
|
||||
The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user).
|
||||
|
||||
The CLI interacts with a [node](../core/node.md) to handle this command. The interface itself is defined in a `main.go` file.
|
||||
|
||||
### Building the CLI
|
||||
|
||||
The `main.go` file needs to have a `main()` function that creates a root command, to which all the application commands will be added as subcommands. The root command additionally handles:
|
||||
|
||||
- **setting configurations** by reading in configuration files (e.g. the sdk config file).
|
||||
- **adding any flags** to it, such as `--chain-id`.
|
||||
- **instantiating the `codec`** by calling the application's `MakeCodec()` function (called `MakeTestEncodingConfig` in `simapp`). The [`codec`](../core/encoding.md) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf.
|
||||
- **adding subcommand** for all the possible user interactions, including [transaction commands](#transaction-commands) and [query commands](#query-commands).
|
||||
|
||||
The `main()` function finally creates an executor and [execute](https://godoc.org/github.com/spf13/cobra#Command.Execute) the root command. See an example of `main()` function from the `simapp` application:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/main.go#L12-L24
|
||||
|
||||
The rest of the document will detail what needs to be implemented for each step and include smaller portions of code from the `simapp` CLI files.
|
||||
|
||||
## Adding Commands to the CLI
|
||||
|
||||
Every application CLI first constructs a root command, then adds functionality by aggregating subcommands (often with further nested subcommands) using `rootCmd.AddCommand()`. The bulk of an application's unique capabilities lies in its transaction and query commands, called `TxCmd` and `QueryCmd` respectively.
|
||||
|
||||
### Root Command
|
||||
|
||||
The root command (called `rootCmd`) is what the user first types into the command line to indicate which application they wish to interact with. The string used to invoke the command (the "Use" field) is typically the name of the application suffixed with `-d`, e.g. `simd` or `gaiad`. The root command typically includes the following commands to support basic functionality in the application.
|
||||
|
||||
- **Status** command from the SDK rpc client tools, which prints information about the status of the connected [`Node`](../core/node.md). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`.
|
||||
- **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys) from the SDK client tools, which includes a collection of subcommands for using the key functions in the SDK crypto tools, including adding a new key and saving it to the keyring, listing all public keys stored in the keyring, and deleting a key. For example, users can type `simd keys add <name>` to add a new key and save an encrypted copy to the keyring, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](../run-node/keyring.md).
|
||||
- **Server** commands from the SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI Tendermint application and provides the CLI framework (based on [cobra](github.com/spf13/cobra)) necessary to fully bootstrap an application. The package exposes two core functions: `StartCmd` and `ExportCmd` which creates commands to start the application and export state respectively. Click [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/server) to learn more.
|
||||
- [**Transaction**](#transaction-commands) commands.
|
||||
- [**Query**](#query-commands) commands.
|
||||
|
||||
Next is an example `rootCmd` function from the `simapp` application. It instantiates the root command, adds a [_persistent_ flag](#flags) and `PreRun` function to be run before every execution, and adds all of the necessary subcommands.
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L37-L93
|
||||
|
||||
The root-level `status` and `keys` subcommands are common across most applications and do not interact with application state. The bulk of an application's functionality - what users can actually _do_ with it - is enabled by its `tx` and `query` commands.
|
||||
|
||||
### Transaction Commands
|
||||
|
||||
[Transactions](./transactions.md) are objects wrapping [`Msg`s](../building-modules/messages-and-queries.md#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCmd` is generally added to the `rootCmd`:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L86-L92
|
||||
|
||||
This `txCmd` function adds all the transaction available to end-users for the application. This typically includes:
|
||||
|
||||
- **Sign command** from the [`auth`](../../x/auth/spec/README.md) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, thithe signing command is necessary for every application.
|
||||
- **Broadcast command** from the SDK client tools, to broadcast transactions.
|
||||
- **All [module transaction commands](../building-modules/module-interfaces.md#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/module-manager.md#basic-manager) `AddTxCommands()` function.
|
||||
|
||||
Here is an example of a `txCmd` aggregating these subcommands from the `simapp` application:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L123-L149
|
||||
|
||||
### Query Commands
|
||||
|
||||
[**Queries**](../building-modules/messages-and-queries.md#queries) are objects that allow users to retrieve information about the application's state. To enable the creation of transactions using the CLI interface, a function `txCmd` is generally added to the `rootCmd`:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L86-L92
|
||||
|
||||
This `queryCmd` function adds all the queries available to end-users for the application. This typically includes:
|
||||
|
||||
- **QueryTx** and/or other transaction query commands] from the `auth` module which allow the user to search for a transaction by inputting its hash, a list of tags, or a block height. These queries allow users to see if transactions have been included in a block.
|
||||
- **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address.
|
||||
- **Validator command** from the SDK rpc client tools, which displays the validator set of a given height.
|
||||
- **Block command** from the SDK rpc client tools, which displays the block data for a given height.
|
||||
- **All [module query commands](../building-modules/module-interfaces.md#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/module-manager.md#basic-manager) `AddQueryCommands()` function.
|
||||
|
||||
Here is an example of a `queryCmd` aggregating subcommands from the `simapp` application:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/0.40.0/simapp/simd/cmd/root.go#L99-L121
|
||||
|
||||
## Flags
|
||||
|
||||
Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with.
|
||||
|
||||
A _persistent_ flag (as opposed to a _local_ flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as _required_ so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently.
|
||||
|
||||
Flags are added to commands directly (generally in the [module's CLI file](../building-modules/module-interfaces.md#flags) where module commands are defined) and no flag except for the `rootCmd` persistent flags has to be added at application level. It is common to add a _persistent_ flag for `--chain-id`, the unique identifier of the blockchain the application pertains to, to the root command. Adding this flag can be done in the `main()` function. Adding this flag makes sense as the chain ID should not be changing across commands in this application CLI. Here is an example from the `simapp` application:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L118
|
||||
|
||||
## Configurations
|
||||
|
||||
It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and maybe modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary.
|
||||
|
||||
Here is an example of an `PersistentPreRun()` function from `simapp``:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L54-L60
|
||||
|
||||
The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistentCommandFlags` which creates a `client.Context` and sets that on the root command's `Context`.
|
||||
|
||||
The `InterceptConfigsPreRunHandler` call creates a viper literal, default `server.Context`, and a logger and sets that on the root command's `Context`. The `server.Context` will be modified and saved to disk via the internal `interceptConfigs` call, which either reads or creates a Tendermint configuration based on the home path provided. In addition, `interceptConfigs` also reads and loads the application configuration, `app.toml`, and binds that to the `server.Context` viper literal. This is vital so the application can get access to not only the CLI flags, but also to the application configuration values provided by this file.
|
||||
|
||||
## Next {hide}
|
||||
|
||||
Learn about [events](./events.md) {hide}
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
<!--
|
||||
order: 8
|
||||
order: 9
|
||||
-->
|
||||
|
||||
# Events
|
||||
|
||||
@@ -26,13 +26,13 @@ Each module exposes [`Msg` and `Query` Protobuf services](../building-modules/me
|
||||
|
||||
https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/server/types/app.go#L39-L41
|
||||
|
||||
The `grpc.Server` is a concrete gRPC server, which spawns and serves any gRPC requests. This server can be configured inside `$TMHOME/config/app.toml`:
|
||||
The `grpc.Server` is a concrete gRPC server, which spawns and serves any gRPC requests. This server can be configured inside `~/.simapp/config/app.toml`:
|
||||
|
||||
- `grpc.enable = true|false` field defines if the gRPC server should be enabled. Defaults to `true`.
|
||||
- `grpc.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `0.0.0.0:9000`.
|
||||
|
||||
::tip
|
||||
`$TMHOME` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`.
|
||||
`~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`.
|
||||
::
|
||||
|
||||
Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](../run-node/interact-node.md#using-grpc) tutorial.
|
||||
@@ -43,11 +43,11 @@ An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Prot
|
||||
|
||||
In Cosmos SDK v0.40, the node continues to serve a REST server. However, the existing routes present in version v0.39 and earlier are now marked as deprecated, and new routes have been added via gRPC-gateway.
|
||||
|
||||
All routes are configured under the following fields in `$TMHOME/config/app.toml`:
|
||||
All routes are configured under the following fields in `~/.simapp/config/app.toml`:
|
||||
|
||||
- `api.enable = true|false` field defines if the REST server should be enabled. Defaults to `true`.
|
||||
- `api.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `tcp://0.0.0.0:1317`.
|
||||
- some additional API configuration options are defined in `$TMHOME/config/app.toml`, along with comments, please refer to that file directly.
|
||||
- some additional API configuration options are defined in `~/.simapp/config/app.toml`, along with comments, please refer to that file directly.
|
||||
|
||||
### gRPC-gateway REST Routes
|
||||
|
||||
@@ -69,13 +69,13 @@ For application developers, Legacy REST API routes needs to be wired up to the R
|
||||
|
||||
A [Swagger](https://swagger.io/) (or OpenAPIv2) specification file is exposed under the `/swagger` route on the API server. Swagger is an open specification describing the API endpoints a server serves, including description, input arguments, return types and much more about each endpoint.
|
||||
|
||||
Enabling the `/swagger` endpoint is configurable inside `$TMHOME/config/app.toml` via the `api.swagger` field, which is set to true by default.
|
||||
Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default.
|
||||
|
||||
For application developers, you may want to generate your own Swagger definitions based on your custom modules. The SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/scripts/protoc-swagger-gen.sh) is a good place to start.
|
||||
|
||||
## Tendermint RPC
|
||||
|
||||
Independently from the Cosmos SDK, Tendermint also exposes a RPC server. This RPC server can be configured by tuning parameters under the `rpc` table in the `$TMHOME/config/config.toml`, the default listening address is `tcp://0.0.0.0:26657`. An OpenAPI specification of all Tendermint RPC endpoints is available [here](https://docs.tendermint.com/master/rpc/).
|
||||
Independently from the Cosmos SDK, Tendermint also exposes a RPC server. This RPC server can be configured by tuning parameters under the `rpc` table in the `~/.simapp/config/config.toml`, the default listening address is `tcp://0.0.0.0:26657`. An OpenAPI specification of all Tendermint RPC endpoints is available [here](https://docs.tendermint.com/master/rpc/).
|
||||
|
||||
Some Tendermint RPC endpoints are directly related to the Cosmos SDK:
|
||||
|
||||
@@ -98,4 +98,4 @@ Some Tendermint RPC endpoints are directly related to the Cosmos SDK:
|
||||
|
||||
## Next {hide}
|
||||
|
||||
Learn about [events](./events.md) {hide}
|
||||
Learn about [the CLI](./cli.md) {hide}
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
<!--
|
||||
order: 10
|
||||
order: 11
|
||||
-->
|
||||
|
||||
# Object-Capability Model
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!--
|
||||
order: 11
|
||||
order: 12
|
||||
-->
|
||||
|
||||
# RunTx recovery middleware
|
||||
@@ -22,12 +22,12 @@ type RecoveryHandler func(recoveryObj interface{}) error
|
||||
|
||||
**Contract:**
|
||||
|
||||
* RecoveryHandler returns `nil` if `recoveryObj` wasn't handled and should be passed to the next recovery middleware;
|
||||
* RecoveryHandler returns a non-nil `error` if `recoveryObj` was handled;
|
||||
- RecoveryHandler returns `nil` if `recoveryObj` wasn't handled and should be passed to the next recovery middleware;
|
||||
- RecoveryHandler returns a non-nil `error` if `recoveryObj` was handled;
|
||||
|
||||
## Custom RecoveryHandler register
|
||||
|
||||
``BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)``
|
||||
`BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)`
|
||||
|
||||
BaseApp method adds recovery middleware to the default recovery chain.
|
||||
|
||||
|
||||
@@ -0,0 +1,101 @@
|
||||
<!--
|
||||
order: 13
|
||||
-->
|
||||
|
||||
# Cosmos Blockchain Simulator
|
||||
|
||||
The Cosmos SDK offers a full fledged simulation framework to fuzz test every
|
||||
message defined by a module.
|
||||
|
||||
On the SDK, this functionality is provided by the[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/app.go), which is a
|
||||
`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation) module.
|
||||
This module defines all the simulation logic as well as the operations for
|
||||
randomized parameters like accounts, balances etc.
|
||||
|
||||
## Goals
|
||||
|
||||
The blockchain simulator tests how the blockchain application would behave under
|
||||
real life circumstances by generating and sending randomized messages.
|
||||
The goal of this is to detect and debug failures that could halt a live chain,
|
||||
by providing logs and statistics about the operations run by the simulator as
|
||||
well as exporting the latest application state when a failure was found.
|
||||
|
||||
Its main difference with integration testing is that the simulator app allows
|
||||
you to pass parameters to customize the chain that's being simulated.
|
||||
This comes in handy when trying to reproduce bugs that were generated in the
|
||||
provided operations (randomized or not).
|
||||
|
||||
## Simulation commands
|
||||
|
||||
The simulation app has different commands, each of which tests a different
|
||||
failure type:
|
||||
|
||||
- `AppImportExport`: The simulator exports the initial app state and then it
|
||||
creates a new app with the exported `genesis.json` as an input, checking for
|
||||
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://golang.org/pkg/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.
|
||||
|
||||
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.
|
||||
Check the full list of flags [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/config.go#L32-L55).
|
||||
|
||||
## Simulator Modes
|
||||
|
||||
In addition to the various inputs and commands, the simulator runs in three modes:
|
||||
|
||||
1. Completely random where the initial state, module parameters and simulation
|
||||
parameters are **pseudo-randomly generated**.
|
||||
2. From a `genesis.json` file where the initial state and the module parameters are defined.
|
||||
This mode is helpful for running simulations on a known state such as a live network export where a new (mostly likely breaking) version of the application needs to be tested.
|
||||
3. From a `params.json` file where the initial state is pseudo-randomly generated but the module and simulation parameters can be provided manually.
|
||||
This allows for a more controlled and deterministic simulation setup while allowing the state space to still be pseudo-randomly simulated.
|
||||
The list of available parameters are listed [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation/params.go#L44-L52).
|
||||
|
||||
::: tip
|
||||
These modes are not mutually exclusive. So you can for example run a randomly
|
||||
generated genesis state (`1`) with manually generated simulation params (`3`).
|
||||
:::
|
||||
|
||||
## Usage
|
||||
|
||||
This is a general example of how simulations are run. For more specific examples
|
||||
check the SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/Makefile#L251-L287).
|
||||
|
||||
```bash
|
||||
$ go test -mod=readonly github.com/cosmos/cosmos-sdk/simapp \
|
||||
-run=TestApp<simulation_command> \
|
||||
...<flags>
|
||||
-v -timeout 24h
|
||||
```
|
||||
|
||||
## Debugging Tips
|
||||
|
||||
Here are some suggestions when encountering a simulation failure:
|
||||
|
||||
- Export the app state at the height were the failure was found. You can do this
|
||||
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.40.0/x/staking/keeper/keeper.go#L66-L69) on your `Keeper`.
|
||||
|
||||
## Use simulation in your SDK-based application
|
||||
|
||||
Learn how you can integrate the simulation into your SDK-based application:
|
||||
|
||||
- Application Simulation Manager
|
||||
- [Building modules: Simulator](../building-modules/simulator.md)
|
||||
- Simulator tests
|
||||
@@ -1,5 +1,5 @@
|
||||
<!--
|
||||
order: 9
|
||||
order: 10
|
||||
-->
|
||||
|
||||
# Telemetry
|
||||
|
||||
Reference in New Issue
Block a user