ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-22 12:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update ter-codes.md

Browse Source
This commit is contained in:
Elliot Lee
2023-07-17 22:12:53 -07:00
committed by GitHub
parent 516638066f
commit 7d9bd91a94
1 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
content/references/protocol-reference/transactions/transaction-results/ter-codes.md
View File

@@ -1,19 +1,19 @@
--- ---
html: ter-codes.html html: ter-codes.html
parent: transaction-results.html parent: transaction-results.html
blurb: ter codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. blurb: ter codes indicate that the transaction has not been applied yet, but it could apply successfully in the future - for example, if some other transaction applies first.
labels: labels:
- Transaction Sending - Transaction Sending
--- ---
# ter Codes # ter Codes
These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range -99 to -1. The exact code for any given error is subject to change, so don't rely on it. These codes indicate that the transaction has not been [applied](consensus.html) yet, and generally will be automatically retried by the server that returned the result code. The transaction could apply successfully in the future; for example, if a certain other transaction applies first. These codes have numerical values in the range -99 to -1, but the exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `ter` codes are not applied the current ledger and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being automatically reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html). **Note:** Transactions with `ter` codes have not been applied to the current ledger and have not yet changed the XRP Ledger state. A transaction that provisionally got a `ter` result may still succeed or fail with a different code after being automatically applied later. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html).
| Code | Explanation | | Code | Explanation |
|:-----------------|:----------------------------------------------------------| |:-----------------|:----------------------------------------------------------|
| `terFUNDS_SPENT` | **DEPRECATED.** | | `terSUBMITTED` | Transaction has been submitted, but not yet applied. |
| `terINSUF_FEE_B` | The account sending the transaction does not have enough XRP to pay the `Fee` specified in the transaction. | | `terINSUF_FEE_B` | The account sending the transaction does not have enough XRP to pay the `Fee` specified in the transaction. |
| `terLAST` | Used internally only. This code should never be returned. | | `terLAST` | Used internally only. This code should never be returned. |
| `terNO_ACCOUNT` | The address sending the transaction is not funded in the ledger (yet). | | `terNO_ACCOUNT` | The address sending the transaction is not funded in the ledger (yet). |
@@ -23,8 +23,9 @@ These codes indicate that the transaction failed, but it could apply successfull
| `terOWNERS` | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](accountset.html#accountset-flags) flag if it has any trust lines or available offers. | | `terOWNERS` | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](accountset.html#accountset-flags) flag if it has any trust lines or available offers. |
| `terPRE_SEQ` | The `Sequence` number of the current transaction is higher than the current sequence number of the account sending the transaction. | | `terPRE_SEQ` | The `Sequence` number of the current transaction is higher than the current sequence number of the account sending the transaction. |
| `terPRE_TICKET` | The transaction attempted to use a [Ticket](tickets.html), but the specified `TicketSequence` number does not exist in the ledger. However, the Ticket could still be created by another transaction. | | `terPRE_TICKET` | The transaction attempted to use a [Ticket](tickets.html), but the specified `TicketSequence` number does not exist in the ledger. However, the Ticket could still be created by another transaction. |
| `terRETRY` | Unspecified retriable error. |
| `terQUEUED` | The transaction met the load-scaled [transaction cost](transaction-cost.html) but did not meet the open ledger requirement, so the transaction has been queued for a future ledger. | | `terQUEUED` | The transaction met the load-scaled [transaction cost](transaction-cost.html) but did not meet the open ledger requirement, so the transaction has been queued for a future ledger. |
| `terRETRY` | Unspecified retriable error. |
| `terFUNDS_SPENT` | **DEPRECATED.** |
<!--{# common link defs #}--> <!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %} {% include '_snippets/rippled-api-links.md' %}