docs: fix the warning syntax error across docs (#6351)

* fix the warning syntax error across docs. * fix rendering of tip admonition --------- Co-authored-by: Carlos Rodriguez <[email protected]> Co-authored-by: Damian Nolan <[email protected]>
cosmos · May 22, 2024 · 23f6751 · 23f6751
1 parent 6993618
commit 23f6751
Show file tree

Hide file tree

Showing 13 changed files with 27 additions and 27 deletions.
diff --git a/docs/docs/01-ibc/03-apps/01-apps.md b/docs/docs/01-ibc/03-apps/01-apps.md
@@ -314,7 +314,7 @@ sequence, err := IBCChannelKeeper.SendPacket(
 )
 ```
 
-::: warning
+:::warning
 In order to prevent modules from sending packets on channels they do not own, IBC expects
 modules to pass in the correct channel capability for the packet's source channel.
 :::

diff --git a/docs/docs/01-ibc/06-channel-upgrades.md b/docs/docs/01-ibc/06-channel-upgrades.md
@@ -70,7 +70,7 @@ As part of the handling of the `MsgChannelUpgradeInit` message, the application'
 
 After this message is handled successfully, the channel's upgrade sequence will be incremented. This upgrade sequence will serve as a nonce for the upgrade process to provide replay protection.
 
-::: warning
+:::warning
 Initiating an upgrade in the same block as opening a channel may potentially prevent the counterparty channel from also opening. 
 :::
 

diff --git a/docs/docs/02-apps/01-transfer/07-params.md b/docs/docs/02-apps/01-transfer/07-params.md
@@ -26,7 +26,7 @@ To prevent a single token from being transferred from the chain, set the `SendEn
 - For Cosmos SDK v0.46.x or earlier, set the bank module's [`SendEnabled` parameter](https://github.com/cosmos/cosmos-sdk/blob/release/v0.46.x/x/bank/spec/05_params.md#sendenabled) for the denomination to `false`.
 - For Cosmos SDK versions above v0.46.x, set the bank module's `SendEnabled` entry for the denomination to `false` using `MsgSetSendEnabled` as a governance proposal.
 
-::: warning
+:::warning
 Doing so will prevent the token from being transferred between any accounts in the blockchain.
 :::
 
@@ -39,7 +39,7 @@ To prevent a single token from being transferred to the chain, set the `ReceiveE
 - For Cosmos SDK v0.46.x or earlier, set the bank module's [`SendEnabled` parameter](https://github.com/cosmos/cosmos-sdk/blob/release/v0.46.x/x/bank/spec/05_params.md#sendenabled) for the denomination to `false`.
 - For Cosmos SDK versions above v0.46.x, set the bank module's `SendEnabled` entry for the denomination to `false` using `MsgSetSendEnabled` as a governance proposal.
 
-::: warning
+:::warning
 Doing so will prevent the token from being transferred between any accounts in the blockchain.
 :::
 

diff --git a/docs/docs/04-middleware/02-callbacks/02-integration.md b/docs/docs/04-middleware/02-callbacks/02-integration.md
@@ -74,7 +74,7 @@ app.TransferKeeper.WithICS4Wrapper(transferICS4Wrapper)
 ibcRouter.AddRoute(ibctransfertypes.ModuleName, transferStack)
 ```
 
-::: warning
+:::warning
 The usage of `WithICS4Wrapper` after `transferStack`'s configuration is critical! It allows the callbacks middleware to do `SendPacket` callbacks and asynchronous `ReceivePacket` callbacks. You must do this regardless of whether you are using the `29-fee` middleware or not.
 :::
 
@@ -108,6 +108,6 @@ AddRoute(icacontrollertypes.SubModuleName, icaControllerStack).
 AddRoute(icahosttypes.SubModuleName, icaHostStack).
 ```
 
-::: warning
+:::warning
 The usage of `WithICS4Wrapper` here is also critical!
 :::
diff --git a/docs/docs/04-middleware/02-callbacks/05-end-users.md b/docs/docs/04-middleware/02-callbacks/05-end-users.md
@@ -18,11 +18,11 @@ This section explains how to use the callbacks middleware from the perspective o
 
 For a given channel, the source callbacks are supported if the source chain has the callbacks middleware wired up in the channel's IBC stack. Similarly, the destination callbacks are supported if the destination chain has the callbacks middleware wired up in the channel's IBC stack.
 
-::: tip
+:::tip
 Callbacks are always executed after the packet has been processed by the underlying IBC module.
 :::
 
-::: warning
+:::warning
 If the underlying application module is doing an asynchronous acknowledgement on packet receive (for example, if the [packet forward middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) is in the stack, and is being used by this packet), then the callbacks middleware will execute the `ReceivePacket` callback after the acknowledgement has been received.
 :::
 
@@ -85,12 +85,12 @@ User defined gas limit was added for the following reasons:
 - To prevent callbacks from blocking packet lifecycle.
 - To prevent relayers from being able to DOS the callback execution by sending a packet with a low amount of gas.
 
-::: tip
+:::tip
 There is a chain wide parameter that sets the maximum gas limit that a user can set for a callback. This is to prevent a user from setting a gas limit that is too high for relayers. If the `"gas_limit"` is not set in the packet memo, then the maximum gas limit is used.
 :::
 
 These goals are achieved by creating a minimum gas amount required for callback execution. If the relayer provides at least the minimum gas limit for the callback execution, then the packet lifecycle will not be blocked if the callback runs out of gas during execution, and the callback cannot be retried. If the relayer does not provided the minimum amount of gas and the callback executions runs out of gas, the entire tx is reverted and it may be executed again.
 
-::: tip
+:::tip
 `SendPacket` callback is always reverted if the callback execution fails or returns an error for any reason. This is so that the packet is not sent if the callback execution fails.
 :::
diff --git a/docs/versioned_docs/version-v7.5.x/01-ibc/03-apps/02-ibcmodule.md b/docs/versioned_docs/version-v7.5.x/01-ibc/03-apps/02-ibcmodule.md
@@ -254,7 +254,7 @@ sequence, err := IBCChannelKeeper.SendPacket(
 )
 ```
 
-::: warning
+:::warning
 In order to prevent modules from sending packets on channels they do not own, IBC expects
 modules to pass in the correct channel capability for the packet's source channel.
 :::

diff --git a/docs/versioned_docs/version-v7.5.x/04-middleware/02-callbacks/02-integration.md b/docs/versioned_docs/version-v7.5.x/04-middleware/02-callbacks/02-integration.md
@@ -69,7 +69,7 @@ app.TransferKeeper.WithICS4Wrapper(transferICS4Wrapper)
 ibcRouter.AddRoute(ibctransfertypes.ModuleName, transferStack)
 ```
 
-::: warning
+:::warning
 The usage of `WithICS4Wrapper` after `transferStack`'s configuration is critical! It allows the callbacks middleware to do `SendPacket` callbacks and asynchronous `ReceivePacket` callbacks. You must do this regardless of whether you are using the `29-fee` middleware or not.
 :::
 
@@ -103,6 +103,6 @@ AddRoute(icacontrollertypes.SubModuleName, icaControllerStack).
 AddRoute(icahosttypes.SubModuleName, icaHostStack).
 ```
 
-::: warning
+:::warning
 The usage of `WithICS4Wrapper` here is also critical!
 :::
diff --git a/docs/versioned_docs/version-v7.5.x/04-middleware/02-callbacks/05-end-users.md b/docs/versioned_docs/version-v7.5.x/04-middleware/02-callbacks/05-end-users.md
@@ -18,11 +18,11 @@ This section explains how to use the callbacks middleware from the perspective o
 
 For a given channel, the source callbacks are supported if the source chain has the callbacks middleware wired up in the channel's IBC stack. Similarly, the destination callbacks are supported if the destination chain has the callbacks middleware wired up in the channel's IBC stack.
 
-::: tip
+:::tip
 Callbacks are always executed after the packet has been processed by the underlying IBC module.
 :::
 
-::: warning
+:::warning
 If the underlying application module is doing an asynchronous acknowledgement on packet receive (for example, if the [packet forward middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) is in the stack, and is being used by this packet), then the callbacks middleware will execute the `ReceivePacket` callback after the acknowledgement has been received.
 :::
 
@@ -85,12 +85,12 @@ User defined gas limit was added for the following reasons:
 - To prevent callbacks from blocking packet lifecycle.
 - To prevent relayers from being able to DOS the callback execution by sending a packet with a low amount of gas.
 
-::: tip
+:::tip
 There is a chain wide parameter that sets the maximum gas limit that a user can set for a callback. This is to prevent a user from setting a gas limit that is too high for relayers. If the `"gas_limit"` is not set in the packet memo, then the maximum gas limit is used.
 :::
 
 These goals are achieved by creating a minimum gas amount required for callback execution. If the relayer provides at least the minimum gas limit for the callback execution, then the packet lifecycle will not be blocked if the callback runs out of gas during execution, and the callback cannot be retried. If the relayer does not provided the minimum amount of gas and the callback executions runs out of gas, the entire tx is reverted and it may be executed again.
 
-::: tip
+:::tip
 `SendPacket` callback is always reverted if the callback execution fails or returns an error for any reason. This is so that the packet is not sent if the callback execution fails.
 :::
diff --git a/docs/versioned_docs/version-v8.3.x/01-ibc/03-apps/01-apps.md b/docs/versioned_docs/version-v8.3.x/01-ibc/03-apps/01-apps.md
@@ -314,7 +314,7 @@ sequence, err := IBCChannelKeeper.SendPacket(
 )
 ```
 
-::: warning
+:::warning
 In order to prevent modules from sending packets on channels they do not own, IBC expects
 modules to pass in the correct channel capability for the packet's source channel.
 :::

diff --git a/docs/versioned_docs/version-v8.3.x/01-ibc/06-channel-upgrades.md b/docs/versioned_docs/version-v8.3.x/01-ibc/06-channel-upgrades.md
@@ -70,7 +70,7 @@ As part of the handling of the `MsgChannelUpgradeInit` message, the application'
 
 After this message is handled successfully, the channel's upgrade sequence will be incremented. This upgrade sequence will serve as a nonce for the upgrade process to provide replay protection.
 
-::: warning
+:::warning
 Initiating an upgrade in the same block as opening a channel may potentially prevent the counterparty channel from also opening. 
 :::
 

diff --git a/docs/versioned_docs/version-v8.3.x/02-apps/01-transfer/07-params.md b/docs/versioned_docs/version-v8.3.x/02-apps/01-transfer/07-params.md
@@ -26,7 +26,7 @@ To prevent a single token from being transferred from the chain, set the `SendEn
 - For Cosmos SDK v0.46.x or earlier, set the bank module's [`SendEnabled` parameter](https://github.com/cosmos/cosmos-sdk/blob/release/v0.46.x/x/bank/spec/05_params.md#sendenabled) for the denomination to `false`.
 - For Cosmos SDK versions above v0.46.x, set the bank module's `SendEnabled` entry for the denomination to `false` using `MsgSetSendEnabled` as a governance proposal.
 
-::: warning
+:::warning
 Doing so will prevent the token from being transferred between any accounts in the blockchain.
 :::
 
@@ -39,7 +39,7 @@ To prevent a single token from being transferred to the chain, set the `ReceiveE
 - For Cosmos SDK v0.46.x or earlier, set the bank module's [`SendEnabled` parameter](https://github.com/cosmos/cosmos-sdk/blob/release/v0.46.x/x/bank/spec/05_params.md#sendenabled) for the denomination to `false`.
 - For Cosmos SDK versions above v0.46.x, set the bank module's `SendEnabled` entry for the denomination to `false` using `MsgSetSendEnabled` as a governance proposal.
 
-::: warning
+:::warning
 Doing so will prevent the token from being transferred between any accounts in the blockchain.
 :::
 

diff --git a/docs/versioned_docs/version-v8.3.x/04-middleware/02-callbacks/02-integration.md b/docs/versioned_docs/version-v8.3.x/04-middleware/02-callbacks/02-integration.md
@@ -69,7 +69,7 @@ app.TransferKeeper.WithICS4Wrapper(transferICS4Wrapper)
 ibcRouter.AddRoute(ibctransfertypes.ModuleName, transferStack)
 ```
 
-::: warning
+:::warning
 The usage of `WithICS4Wrapper` after `transferStack`'s configuration is critical! It allows the callbacks middleware to do `SendPacket` callbacks and asynchronous `ReceivePacket` callbacks. You must do this regardless of whether you are using the `29-fee` middleware or not.
 :::
 
@@ -103,6 +103,6 @@ AddRoute(icacontrollertypes.SubModuleName, icaControllerStack).
 AddRoute(icahosttypes.SubModuleName, icaHostStack).
 ```
 
-::: warning
+:::warning
 The usage of `WithICS4Wrapper` here is also critical!
 :::
diff --git a/docs/versioned_docs/version-v8.3.x/04-middleware/02-callbacks/05-end-users.md b/docs/versioned_docs/version-v8.3.x/04-middleware/02-callbacks/05-end-users.md
@@ -18,11 +18,11 @@ This section explains how to use the callbacks middleware from the perspective o
 
 For a given channel, the source callbacks are supported if the source chain has the callbacks middleware wired up in the channel's IBC stack. Similarly, the destination callbacks are supported if the destination chain has the callbacks middleware wired up in the channel's IBC stack.
 
-::: tip
+:::tip
 Callbacks are always executed after the packet has been processed by the underlying IBC module.
 :::
 
-::: warning
+:::warning
 If the underlying application module is doing an asynchronous acknowledgement on packet receive (for example, if the [packet forward middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) is in the stack, and is being used by this packet), then the callbacks middleware will execute the `ReceivePacket` callback after the acknowledgement has been received.
 :::
 
@@ -85,12 +85,12 @@ User defined gas limit was added for the following reasons:
 - To prevent callbacks from blocking packet lifecycle.
 - To prevent relayers from being able to DOS the callback execution by sending a packet with a low amount of gas.
 
-::: tip
+:::tip
 There is a chain wide parameter that sets the maximum gas limit that a user can set for a callback. This is to prevent a user from setting a gas limit that is too high for relayers. If the `"gas_limit"` is not set in the packet memo, then the maximum gas limit is used.
 :::
 
 These goals are achieved by creating a minimum gas amount required for callback execution. If the relayer provides at least the minimum gas limit for the callback execution, then the packet lifecycle will not be blocked if the callback runs out of gas during execution, and the callback cannot be retried. If the relayer does not provided the minimum amount of gas and the callback executions runs out of gas, the entire tx is reverted and it may be executed again.
 
-::: tip
+:::tip
 `SendPacket` callback is always reverted if the callback execution fails or returns an error for any reason. This is so that the packet is not sent if the callback execution fails.
 :::