Merge remote-tracking branch 'origin/main' into localhost

cosmos · Oct 7, 2024 · e2a8bad · e2a8bad
2 parents 0f4bc90 + 3af3462
commit e2a8bad
Show file tree

Hide file tree

Showing 7 changed files with 7 additions and 7 deletions.
diff --git a/.github/workflows/callbacks.yml b/.github/workflows/callbacks.yml
@@ -62,7 +62,7 @@ jobs:
     steps:
       - name: sonarcloud
         if: ${{ env.GIT_DIFF && !github.event.pull_request.draft && env.SONAR_TOKEN != null }}
-        uses: SonarSource/sonarcloud-github-action@v3.0.0
+        uses: SonarSource/sonarcloud-github-action@v3.1.0
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

diff --git a/.github/workflows/proto-registry.yml b/.github/workflows/proto-registry.yml
@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: bufbuild/buf-setup-action@v1.43.0
+      - uses: bufbuild/buf-setup-action@v1.44.0
       - uses: bufbuild/buf-push-action@v1
         with:
           input: "proto"

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -146,7 +146,7 @@ jobs:
           name: '${{ github.sha }}-03-coverage'
       - name: sonarcloud
         if: ${{ env.GIT_DIFF && !github.event.pull_request.draft }}
-        uses: SonarSource/sonarcloud-github-action@v3.0.0
+        uses: SonarSource/sonarcloud-github-action@v3.1.0
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
diff --git a/.github/workflows/wasm-client.yml b/.github/workflows/wasm-client.yml
@@ -68,7 +68,7 @@ jobs:
     steps:
       - name: sonarcloud
         if: ${{ env.GIT_DIFF && !github.event.pull_request.draft && env.SONAR_TOKEN != null }}
-        uses: SonarSource/sonarcloud-github-action@v3.0.0
+        uses: SonarSource/sonarcloud-github-action@v3.1.0
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

diff --git a/docs/docs/03-light-clients/05-tendermint/01-overview.md b/docs/docs/03-light-clients/05-tendermint/01-overview.md
@@ -23,7 +23,7 @@ The Tendermint client consists of two important structs that keep track of the s
 
 Each Tendermint Client is composed of a single `ClientState` keyed on the client ID, and multiple consensus states which are keyed on both the clientID and header height. Relayers can use the consensus states to verify merkle proofs of packet commitments, acknowledgements, and receipts against the `AppHash` of the counterparty chain in order to enable verified packet flow.
 
-If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occuring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred.
+If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occurring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred.
 
 ## Initialization
 

diff --git a/docs/tutorials/02-channel-upgrades/05-upgrade-channel.md b/docs/tutorials/02-channel-upgrades/05-upgrade-channel.md
@@ -122,7 +122,7 @@ proposals:
 
 Now we wait for the relayer to complete the upgrade handshake.
 
-## Check ugprade completed
+## Check upgrade completed
 
 Once the handshake has completed we verify that the channel has successfully upgraded:
 

diff --git a/docs/versioned_docs/version-v9.0.x/03-light-clients/05-tendermint/01-overview.md b/docs/versioned_docs/version-v9.0.x/03-light-clients/05-tendermint/01-overview.md
@@ -23,7 +23,7 @@ The Tendermint client consists of two important structs that keep track of the s
 
 Each Tendermint Client is composed of a single `ClientState` keyed on the client ID, and multiple consensus states which are keyed on both the clientID and header height. Relayers can use the consensus states to verify merkle proofs of packet commitments, acknowledgements, and receipts against the `AppHash` of the counterparty chain in order to enable verified packet flow.
 
-If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occuring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred.
+If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occurring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred.
 
 ## Initialization