Merge branch 'master' into mconcat/iavl-iterator

cosmos · Oct 31, 2021 · f0b255f · f0b255f
2 parents ade8511 + 479485f
commit f0b255f
Show file tree

Hide file tree

Showing 253 changed files with 8,573 additions and 1,013 deletions.
diff --git a/.github/workflows/lint-pr.yml b/.github/workflows/lint-pr.yml
@@ -11,6 +11,6 @@ jobs:
   main:
     runs-on: ubuntu-latest
     steps:
-      - uses: amannn/[email protected].2
+      - uses: amannn/[email protected].5
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -38,39 +38,43 @@ jobs:
         with:
           PATTERNS: |
             **/**.go
-            go.mod
-            go.sum
+            **/go.mod
+            **/go.sum
       - name: Build
         run: GOARCH=${{ matrix.go-arch }} LEDGER_ENABLED=false make build
 
-  test-cosmovisor:
+      - name: Build cosmovisor
+        run: GOARCH=${{ matrix.go-arch }} LEDGER_ENABLED=false make cosmovisor
+
+  test-submodules:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
       - uses: actions/[email protected]
         with:
           go-version: 1.17
-      - name: Display go version
-        run: go version
       - uses: technote-space/get-diff-action@v5
         id: git_diff
         with:
-          PREFIX_FILTER: |
-            cosmovisor
           PATTERNS: |
             **/**.go
             go.mod
             go.sum
-      - name: Run cosmovisor tests
-        run: cd cosmovisor; make
+      - name: Run submodule tests and create test coverage profile.
+        # GIT_DIFF is passed to the scripts
+        run: bash scripts/module-tests.sh
         if: env.GIT_DIFF
+      - uses: actions/upload-artifact@v2
+        with:
+          name: "${{ github.sha }}-go-submodules-coverage"
+          path: ./coverage-go-submod-profile.out
 
   split-test-files:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
-      - name: Create a file with all the pkgs
-        run: go list ./... > pkgs.txt
+      - name: Create a file with all core Cosmos SDK pkgs
+        run:  go list ./... > pkgs.txt
       - name: Split pkgs into 4 files
         run: split -d -n l/4 pkgs.txt pkgs.txt.part.
       # cache multiple
@@ -149,6 +153,10 @@ jobs:
         with:
           name: "${{ github.sha }}-03-coverage"
         if: env.GIT_DIFF
+      - uses: actions/download-artifact@v2
+        with:
+          name: "${{ github.sha }}-go-submodules-coverage"
+        if: env.GIT_DIFF
       - run: |
           cat ./*profile.out | grep -v "mode: atomic" >> coverage.txt
         if: env.GIT_DIFF

diff --git a/CHANGELOG.md b/CHANGELOG.md
diff --git a/CODING_GUIDELINES.md b/CODING_GUIDELINES.md
@@ -5,9 +5,9 @@ This document is an extension to [CONTRIBUTING](./CONTRIBUTING.md) and provides
 ## API & Design
 
 + Code must be well structured:
-  + packages must have a limited responsibility (different concerns can go to different packages),
-  + types must be easy to compose,
-  + think about maintainbility and testability.
+    + packages must have a limited responsibility (different concerns can go to different packages),
+    + types must be easy to compose,
+    + think about maintainbility and testability.
 + "Depend upon abstractions, [not] concretions".
 + Try to limit the number of methods you are exposing. It's easier to expose something later than to hide it.
 + Take advantage of `internal` package concept.
@@ -19,20 +19,22 @@ This document is an extension to [CONTRIBUTING](./CONTRIBUTING.md) and provides
 + Limit third-party dependencies.
 
 Performance:
+
 + Avoid unnecessary operations or memory allocations.
 
 Security:
+
 + Pay proper attention to exploits involving:
-  + gas usage
-  + transaction verification and signatures
-  + malleability
-  + code must be always deterministic
+    + gas usage
+    + transaction verification and signatures
+    + malleability
+    + code must be always deterministic
 + Thread safety. If some functionality is not thread-safe, or uses something that is not thread-safe, then clearly indicate the risk on each level.
 
-
 ## Testing
 
 Make sure your code is well tested:
+
 + Provide unit tests for every unit of your code if possible. Unit tests are expected to comprise 70%-80% of your tests.
 + Describe the test scenarios you are implementing for integration tests.
 + Create integration tests for queries and msgs.
@@ -64,6 +66,7 @@ for tcIndex, tc := range cases {
 ## Quality Assurance
 
 We are forming a QA team that will support the core Cosmos SDK team and collaborators by:
+
 - Improving the Cosmos SDK QA Processes
 - Improving automation in QA and testing
 - Defining high-quality metrics
@@ -83,5 +86,4 @@ Desired outcomes:
 - Releases are more predictable.
 - QA reports. Goal is to guide with new tasks and be one of the QA measures.
 
-
 As a developer, you must help the QA team by providing instructions for User Experience (UX) and functional testing.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -23,11 +23,13 @@ discussion or proposing code changes. To ensure a smooth workflow for all
 contributors, the general procedure for contributing has been established:
 
 1. Start by browsing [new issues](https://github.com/cosmos/cosmos-sdk/issues) and [discussions](https://github.com/cosmos/cosmos-sdk/discussions). If you are looking for something interesting or if you have something in your mind, there is a chance it was has been discussed.
-  - Looking for a good place to start contributing? How about checking out some [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)?
+
+- Looking for a good place to start contributing? How about checking out some [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)?
+
 2. Determine whether a GitHub issue or discussion is more appropriate for your needs:
-  1. If want to propose something new that requires specification or an additional design, or you would like to change a process, start with a [new discussion](https://github.com/cosmos/cosmos-sdk/discussions/new). With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues.
-   2. If the issue you want addressed is a specific proposal or a bug, then open a [new issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose).
-   3. Review existing [issues](https://github.com/cosmos/cosmos-sdk/issues) to find an issue you'd like to help with.
+1. If want to propose something new that requires specification or an additional design, or you would like to change a process, start with a [new discussion](https://github.com/cosmos/cosmos-sdk/discussions/new). With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues.
+2. If the issue you want addressed is a specific proposal or a bug, then open a [new issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose).
+3. Review existing [issues](https://github.com/cosmos/cosmos-sdk/issues) to find an issue you'd like to help with.
 3. Participate in thoughtful discussion on that issue.
 4. If you would like to contribute:
    1. Ensure that the proposal has been accepted.
@@ -38,7 +40,7 @@ contributors, the general procedure for contributing has been established:
       to begin work.
 5. To submit your work as a contribution to the repository follow standard GitHub best practices. See [pull request guideline](#pull-requests) below.
 
-**Note: ** For very small or blatantly obvious problems such as typos, you are
+**Note:** For very small or blatantly obvious problems such as typos, you are
 not required to an open issue to submit a PR, but be aware that for more complex
 problems/features, if a PR is opened before an adequate design discussion has
 taken place in a GitHub issue, that PR runs a high likelihood of being rejected.
@@ -52,14 +54,14 @@ The developers are organized in working groups which are listed on a ["Working G
 The important development announcements are shared on [Discord](https://discord.com/invite/cosmosnetwork) in the \#dev-announcements channel.
 
 To synchronize we have few major meetings:
+
 + Architecture calls: bi-weekly on Fridays at 14:00 UTC (alternating with the grooming meeting below).
 + Grooming / Planning: bi-weekly on Fridays at 14:00 UTC (alternating with the architecture meeting above).
 + Cosmos Community SDK Development Call on the last Wednesday of every month at 17:00 UTC.
 + Cosmos Roadmap Prioritization every 4 weeks on Tuesday at 15:00 UTC (limited participation).
 
 If you would like to join one of those calls, then please contact us on [Discord](https://discord.com/invite/cosmosnetwork) or reach out directly to Cory Levinson from Regen Network ([email protected]).
 
-
 ## Architecture Decision Records (ADR)
 
 When proposing an architecture decision for the Cosmos SDK, please start by opening an [issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or a [discussion](https://github.com/cosmos/cosmos-sdk/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
@@ -70,11 +72,11 @@ When proposing an architecture decision for the Cosmos SDK, please start by open
 - `master` must never fail `make lint test test-race`.
 - No `--force` onto `master` (except when reverting a broken commit, which should seldom happen).
 - Create a branch to start a wok:
-  - Fork the repo (core developers must create a branch directly in the Cosmos SDK repo),
+    - Fork the repo (core developers must create a branch directly in the Cosmos SDK repo),
     branch from the HEAD of `master`, make some commits, and submit a PR to `master`.
-  - For core developers working within the `cosmos-sdk` repo, follow branch name conventions to ensure a clear
+    - For core developers working within the `cosmos-sdk` repo, follow branch name conventions to ensure a clear
     ownership of branches: `{moniker}/{issue#}-branch-name`.
-  - See [Branching Model](#branching-model-and-release) for more details.
+    - See [Branching Model](#branching-model-and-release) for more details.
 - Be sure to run `make format` before every commit. The easiest way
   to do this is have your editor run it for you upon saving a file (most of the editors
   will do it anyway using a pre-configured setup of the programming language mode).
@@ -92,10 +94,12 @@ Tests can be executed by running `make test` at the top level of the Cosmos SDK
 ### Pull Requests
 
 Before submitting a pull request:
+
 - merge the latest master `git merge origin/master`,
 - run `make lint test` to ensure that all checks and tests pass.
 
 Then:
+
 1. If you have something to show, **start with a `Draft` PR**. It's good to have early validation of your work and we highly recommend this practice. A Draft PR also indicates to the community that the work is in progress.
    Draft PRs also helps the core team provide early feedback and ensure the work is in the right direction.
 2. When the code is complete, change your PR from `Draft` to `Ready for Review`.

diff --git a/Makefile b/Makefile
@@ -109,7 +109,7 @@ BUILD_TARGETS := build install
 
 build: BUILD_ARGS=-o $(BUILDDIR)/
 build-linux:
-	GOOS=linux GOARCH=amd64 LEDGER_ENABLED=false $(MAKE) build
+	GOOS=linux GOARCH=$(if $(findstring aarch64,$(shell uname -m)) || $(findstring arm64,$(shell uname -m)),arm64,amd64) LEDGER_ENABLED=false $(MAKE) build
 
 $(BUILD_TARGETS): go.sum $(BUILDDIR)/
 	go $@ -mod=readonly $(BUILD_FLAGS) $(BUILD_ARGS) ./...
@@ -125,7 +125,7 @@ build-simd-all: go.sum
         --env VERSION=$(VERSION) \
         --env COMMIT=$(COMMIT) \
         --env LEDGER_ENABLED=$(LEDGER_ENABLED) \
-        --name latest-build cosmossdk/rbuilder:latest
+        --name latest-build tendermintdev/rbuilder:latest
 	$(DOCKER) cp -a latest-build:/home/builder/artifacts/ $(CURDIR)/
 
 build-simd-linux: go.sum $(BUILDDIR)/
@@ -136,7 +136,7 @@ build-simd-linux: go.sum $(BUILDDIR)/
         --env VERSION=$(VERSION) \
         --env COMMIT=$(COMMIT) \
         --env LEDGER_ENABLED=false \
-        --name latest-build cosmossdk/rbuilder:latest
+        --name latest-build tendermintdev/rbuilder:latest
 	$(DOCKER) cp -a latest-build:/home/builder/artifacts/ $(CURDIR)/
 	cp artifacts/simd-*-linux-amd64 $(BUILDDIR)/simd
 

diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md
@@ -7,33 +7,35 @@ This document outlines the process for releasing a new version of Cosmos SDK, wh
 A _major release_ is an increment of the first number (eg: `v1.2` → `v2.0.0`) or the _point number_ (eg: `v1.1 → v1.2.0`, also called _point release_). Each major release opens a _stable release series_ and receives updates outlined in the [Major Release Maintenance](#major-release-maintenance)_section.
 
 Before making a new _major_ release we do beta and release candidate releases. For example, for release 1.0.0:
+
 ```
 v1.0.0-beta1 → v1.0.0-beta2 → ... → v1.0.0-rc1 → v1.0.0-rc2 → ... → v1.0.0
 ```
 
 - Release a first beta version on the `master` branch and freeze `master` from receiving any new features. After beta is released, we focus on releasing the release candidate:
-  - finish audits and reviews
-  - kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
-  - perform functional tests
-  - add more tests
-  - release new beta version as the bugs are discovered and fixed.
+    - finish audits and reviews
+    - kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
+    - perform functional tests
+    - add more tests
+    - release new beta version as the bugs are discovered and fixed.
 - After the team feels that the `master` works fine we create a `release/vY` branch (going forward known a release branch), where `Y` is the version number, with the patch part substituted to `x` (eg: 0.42.x, 1.0.x). Ensure the release branch is protected so that pushes against the release branch are permitted only by the release manager or release coordinator.
     - **PRs targeting this branch can be merged _only_ when exceptional circumstances arise**
     - update the GitHub mergify integration by adding instructions for automatically backporting commits from `master` to the `release/vY` using the `backport/Y` label.
 - In the release branch, prepare a new version section in the `CHANGELOG.md`
     - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
     - Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on GitHub.
 - Create a new annotated git tag for a release candidate  (eg: `git tag -a v1.1.0-rc1`) in the release branch.
-  - from this point we unfreeze master.
-  - the SDK teams collaborate and do their best to run testnets in order to validate the release.
-  - when bugs are found, create a PR for `master`, and backport fixes to the release branch.
-  - create new release candidate tags after bugs are fixed.
+    - from this point we unfreeze master.
+    - the SDK teams collaborate and do their best to run testnets in order to validate the release.
+    - when bugs are found, create a PR for `master`, and backport fixes to the release branch.
+    - create new release candidate tags after bugs are fixed.
 - After the team feels the release branch is stable and everything works, create a full release:
-  - update `CHANGELOG.md`.
-  - create a new annotated git tag (eg `git -a v1.1.0`) in the release branch.
-  - Create a GitHub release.
+    - update `CHANGELOG.md`.
+    - create a new annotated git tag (eg `git -a v1.1.0`) in the release branch.
+    - Create a GitHub release.
 
 Following _semver_ philosophy, point releases after `v1.0`:
+
 - must not break API
 - can break consensus
 
@@ -54,11 +56,11 @@ Lastly, it is core team's responsibility to ensure that the PR meets all the SRU
 Point Release must follow the [Stable Release Policy](#stable-release-policy).
 
 After the release branch has all commits required for the next patch release:
+
 - update `CHANGELOG.md`.
 - create a new annotated git tag (eg `git -a v1.1.0`) in the release branch.
 - Create a GitHub release.
 
-
 ## Major Release Maintenance
 
 Major Release series continue to receive bug fixes (released as a Patch Release) until they reach **End Of Life**.
@@ -70,7 +72,6 @@ Only the following major release series have a stable release status:
 * **0.42 «Stargate»** will be supported until 6 months after **0.43.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
 * **0.44** is the latest major release.
 
-
 ## Stable Release Policy
 
 ### Patch Releases

diff --git a/baseapp/abci.go b/baseapp/abci.go
@@ -195,6 +195,14 @@ func (app *BaseApp) BeginBlock(req abci.RequestBeginBlock) (res abci.ResponseBeg
 	}
 	// set the signed validators for addition to context in deliverTx
 	app.voteInfos = req.LastCommitInfo.GetVotes()
+
+	// call the hooks with the BeginBlock messages
+	for _, streamingListener := range app.abciListeners {
+		if err := streamingListener.ListenBeginBlock(app.deliverState.ctx, req, res); err != nil {
+			app.logger.Error("BeginBlock listening hook failed", "height", req.Header.Height, "err", err)
+		}
+	}
+
 	return res
 }
 
@@ -215,6 +223,13 @@ func (app *BaseApp) EndBlock(req abci.RequestEndBlock) (res abci.ResponseEndBloc
 		res.ConsensusParamUpdates = cp
 	}
 
+	// call the streaming service hooks with the EndBlock messages
+	for _, streamingListener := range app.abciListeners {
+		if err := streamingListener.ListenEndBlock(app.deliverState.ctx, req, res); err != nil {
+			app.logger.Error("EndBlock listening hook failed", "height", req.Height, "err", err)
+		}
+	}
+
 	return res
 }
 
@@ -262,15 +277,25 @@ func (app *BaseApp) CheckTx(req abci.RequestCheckTx) abci.ResponseCheckTx {
 func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx {
 	defer telemetry.MeasureSince(time.Now(), "abci", "deliver_tx")
 
+	var res abci.ResponseDeliverTx
+	defer func() {
+		for _, streamingListener := range app.abciListeners {
+			if err := streamingListener.ListenDeliverTx(app.deliverState.ctx, req, res); err != nil {
+				app.logger.Error("DeliverTx listening hook failed", "err", err)
+			}
+		}
+	}()
 	tx, err := app.txDecoder(req.Tx)
 	if err != nil {
-		return sdkerrors.ResponseDeliverTx(err, 0, 0, app.trace)
+		res = sdkerrors.ResponseDeliverTx(err, 0, 0, app.trace)
+		return res
 	}
 
 	ctx := app.getContextForTx(runTxModeDeliver, req.Tx)
-	res, err := app.txHandler.DeliverTx(ctx, tx, req)
+	res, err = app.txHandler.DeliverTx(ctx, tx, req)
 	if err != nil {
-		return sdkerrors.ResponseDeliverTx(err, uint64(res.GasUsed), uint64(res.GasWanted), app.trace)
+		res = sdkerrors.ResponseDeliverTx(err, uint64(res.GasUsed), uint64(res.GasWanted), app.trace)
+		return res
 	}
 
 	return res

diff --git a/baseapp/baseapp.go b/baseapp/baseapp.go
@@ -4,7 +4,6 @@ import (
 	"context"
 	"errors"
 	"fmt"
-	"reflect"
 
 	abci "github.com/tendermint/tendermint/abci/types"
 	"github.com/tendermint/tendermint/libs/log"
@@ -126,6 +125,10 @@ type BaseApp struct { // nolint: maligned
 	// indexEvents defines the set of events in the form {eventType}.{attributeKey},
 	// which informs Tendermint what to index. If empty, all events will be indexed.
 	indexEvents map[string]struct{}
+
+	// abciListeners for hooking into the ABCI message processing of the BaseApp
+	// and exposing the requests and responses to external consumers
+	abciListeners []ABCIListener
 }
 
 // NewBaseApp returns a reference to an initialized BaseApp. It accepts a
@@ -202,7 +205,7 @@ func (app *BaseApp) MountStores(keys ...storetypes.StoreKey) {
 			app.MountStore(key, storetypes.StoreTypeTransient)
 
 		default:
-			panic("Unrecognized store key type " + reflect.TypeOf(key).Name())
+			panic(fmt.Sprintf("Unrecognized store key type :%T", key))
 		}
 	}
 }