MASQ-Project
[DUPLICATE] Design treatment for too long pending transactions
With the arrival of MASQ-Project/MASQ-Node-issues#523 we have a very simple mechanism that concerns monitoring pending transactions with regard to the how long is it taking for the transaction to come to completion. Some may stay pending even for a long time.
Now we only call all transactions older 6 hours bad transactions and we mark them with the failure mark - that means we just give all the responsibility over to the user's hands, because no other transaction for the same account can be send now and also the user has to decide what to do to solve the cause of the failure (moreover the hypothetically failed transaction can be later confirmed as successful because we don't really know if it's not going to succeed)
Suggestions: We probably want to provide the standard functionality, that is, to automatically resent the transaction with higher gas price (increased by some percentage) when we've passed enough long time from the creation of the transaction.
There is another suggestion regarding the way how we should measure the passed time. The straightforward method is just counting with time units; the more sophisticated way is by the number of chain blocks added after the block from moment of sending the transaction.
The latter method requires us to be able to retrieve the current block number which may cause the need of another RPC-JSON call to the blockchain.
Be aware that these issues are linked to pending transactions being in air for a while, quick failures don't fall under these and so, of course, we won't want to retry the failed transaction at least not until we are able to determine the right cause of the failure.
@bertllll your logic here is sound and the alternatives are fairly logical here, in order:
- reduce the failure mark greatly and consider making it a function of the scan intervals nodes are using, and quite possibly translate this into a metric of how many blocks have been added since sending
- we could implement a user-option or statup flag (like Dan performed for the
--scansstartup flag) that a user could choose which allows Node to resend a transaction at the failure mark with 10% more gas (I've read in other places this is a standard practice to resend a failed or stuck transaction which was pending too long or failed from gas parameters being too low)
