ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 03:35:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Migrate old callout syntax

Browse Source
This commit is contained in:
mDuo13
2024-10-09 15:26:34 -07:00
parent 4d3d3edece
commit f42bb6c813
364 changed files with 607 additions and 603 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/concepts/transactions/transaction-queue.md
View File

@@ -30,7 +30,7 @@ The transaction queue plays an important role in selecting the transactions that
After this step, the process repeats from the beginning.
**Note:** Technically, several of the steps described in the above process occur in parallel, because each server is always listening for new transactions, and starts preparing its next ledger proposal while the consensus process for the previous ledger version is ongoing.
{% admonition type="info" name="Note" %}Technically, several of the steps described in the above process occur in parallel, because each server is always listening for new transactions, and starts preparing its next ledger proposal while the consensus process for the previous ledger version is ongoing.{% /admonition %}
## Queuing Restrictions
@@ -64,7 +64,7 @@ Within the transaction queue, transactions are ranked so that transactions payin
The precise order of transactions in the queue decides which transactions get added to the next in-progress ledger version in cases where there are more transactions in the queue than the expected size of the next ledger version. The order of the transactions **does not affect the order the transactions are executed within a validated ledger**. In each validated ledger version, the transaction set for that version executes in [canonical order](../consensus-protocol/consensus-structure.md#calculate-and-share-validations).
**Note:** When `rippled` queues a transaction, the provisional [transaction response code](../../references/protocol/transactions/transaction-results/index.md) is `terQUEUED`. This means that the transaction is likely to succeed in a future ledger version. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or [rendered permanently invalid](finality-of-results/index.md).
{% admonition type="info" name="Note" %}When `rippled` queues a transaction, the provisional [transaction response code](../../references/protocol/transactions/transaction-results/index.md) is `terQUEUED`. This means that the transaction is likely to succeed in a future ledger version. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or [rendered permanently invalid](finality-of-results/index.md).{% /admonition %}
## See Also