Encounter telINSUF_FEE_P although my account balance has enough XRP
I use RippleLib to build the transaction, here is the code:
const tag = [tag];
const amount = { value: [gross_amount], currency: 'XRP' };
const payment = {
source: { address: [from], maxAmount: amount },
destination: { address: [to], amount, tag },
};
const options = { fee: [estimateFee], maxLedgerVersion: null };
const unsignedTx = await rippleLib.preparePayment([from], payment, options);
// The rest it the sign process...
Should be validated in a ledger
telINSUF_FEE_P
Ripple public main net s2: https://s2.ripple.com:51234/
Maybe it doesn't have enough XRP after all? Also the server could be overloaded, have you tried on a locally running rippled?
What is the value of [estimateFee]?
12 drop here is the error log, I have removed all the sensitive info:
{
"accepted":true,
"account_sequence_available":1947,
"account_sequence_next":1947,
"applied":false,
"broadcast":false,
"engine_result":"telINSUF_FEE_P",
"engine_result_code":-394,
"engine_result_message":"Fee insufficient.",
"kept":true,
"open_ledger_cost":"10",
"queued":false,
"status":"success",
"tx_blob":"12000022800...",
"tx_json":{
"Account":"[from]",
"Amount":"234750000",
"Destination":"[to]",
"DestinationTag":2116739,
"Fee":"12",
"Flags":2147483648,
"Sequence":1947,
"SigningPubKey":"[hidden]",
"TransactionType":"Payment",
"TxnSignature":"[hidden]",
"hash":"[hidden]"
},
"validated_ledger_index":57748664
}
Actually, it happens again with me today, it still logs this error, but this time, after a while the tx is validated in a ledger.
There are a few different ways a transaction can get a telINSUF_FEE_P provisional result, but the most likely is that the fee is that the particular node was experiencing high load, and thus the local load factor was elevated. This local load factor is applied to the ledger's minimum required fee (10 drops, assuming it's a typical single signed transaction) to get the minimum local fee. For example, if the load factor is 10.5, then any transaction paying less than 10.5*10drops=105 drops will get this result.
The good news is that the load factor can drop quickly after a ledger or two, and if you didn't use the fail_hard option, your transaction will be held by that node for a short time and retried a few times before it's completely dropped. If you have the transaction hash, or the account ID and transaction sequence number, you can query the ledger to see if the transaction succeed later. You should be doing this anyway because the provisional result is not guaranteed to be the final result, and not checking the final result can lead to other problems. See https://xrpl.org/reliable-transaction-submission.html#reliable-transaction-submission for more info.
Finally, you didn't go into any detail about your use case, but I'll mention here that s2 is a shared public resource primarily to allow querying the full ledger history. I believe that s1 has a lot more resources available for things like transaction submission without being as likely to get bogged down. However, s1 is a shared public resource, too. For anything other than experimentation, short-term development, or one-off requests, we strongly recommend that you run your own rippled node. Running your own node allows you to control and restrict access, gain more insight into the state of your node and the ledger, and helps support the larger XRPL community. See https://xrpl.org/manage-the-rippled-server.html for more info.
Hi, good knowledge on the fail_hard option, I will update it to my code and will handle the retry part myself. For the issue, although I haven't changed anything since then, I also haven't encountered this error anymore. I also don't know how to reproduce the error so I think I will close this for now. Thanks for your support
Most helpful comment
There are a few different ways a transaction can get a
telINSUF_FEE_Pprovisional result, but the most likely is that the fee is that the particular node was experiencing high load, and thus the local load factor was elevated. This local load factor is applied to the ledger's minimum required fee (10 drops, assuming it's a typical single signed transaction) to get the minimum local fee. For example, if the load factor is 10.5, then any transaction paying less than 10.5*10drops=105 drops will get this result.The good news is that the load factor can drop quickly after a ledger or two, and if you didn't use the
fail_hardoption, your transaction will be held by that node for a short time and retried a few times before it's completely dropped. If you have the transaction hash, or the account ID and transaction sequence number, you can query the ledger to see if the transaction succeed later. You should be doing this anyway because the provisional result is not guaranteed to be the final result, and not checking the final result can lead to other problems. See https://xrpl.org/reliable-transaction-submission.html#reliable-transaction-submission for more info.Finally, you didn't go into any detail about your use case, but I'll mention here that s2 is a shared public resource primarily to allow querying the full ledger history. I believe that s1 has a lot more resources available for things like transaction submission without being as likely to get bogged down. However, s1 is a shared public resource, too. For anything other than experimentation, short-term development, or one-off requests, we strongly recommend that you run your own rippled node. Running your own node allows you to control and restrict access, gain more insight into the state of your node and the ledger, and helps support the larger XRPL community. See https://xrpl.org/manage-the-rippled-server.html for more info.