Closed ebma closed 5 months ago
Great PR, this will be a big improvement for the UX.
In theory the logic could be caught in a cycle where the fee is already at the 1 XLM maximum and will be resubmitted repeatedly. Not sure whether such a scenario will ever happen. But anyway: would that be a problem for the vault?
In theory the logic could be caught in a cycle where the fee is already at the 1 XLM maximum and will be resubmitted repeatedly. Not sure whether such a scenario will ever happen. But anyway: would that be a problem for the vault?
Yes, that's true but it should not be a problem. As you said, the vault will continue resubmitting the transaction with a fee of 1 XLM but assuming that the load on the Stellar network fluctuates, the vault will manage to submit that transaction eventually. If the traffic on the Stellar network ever gets so high that every transaction needs to pay at least 1 XLM to go through, we would definitely need to revisit this change again though.
This PR adds handling for 'tx_insufficient_fee' errors.
We create a new transaction with a fee that is 10 times higher than the previous one. This 10x factor is adopted from the requirement of FeeBump transactions, see here. We cannot use fee bump transactions however, as we did not add proper handling for them in the stellar-relay pallet here. Using fee bump transactions here is not necessary though as they were introduced with a different purpose in mind. For more information see this blog post.
The increased fee will not go beyond the maximum of 1 XLM. This amount was chosen arbitrarily and we could think about making this configurable so that each vault operator can choose this value but it should be fine not to make this configurable for the time being.
Closes #499.