Allow dependent tx issuance over the wallet API #1413
Conversation
| w.pendingTxs.Delete(txID) | ||
|
|
||
| for { |
There was a problem hiding this comment.
Can we document or just help me understand, why pop off oldest transaction only once, and exit the for-loop on success? Trying to understand how decided function relates to this operation.
There was a problem hiding this comment.
To rephrase my question,
Allow dependent tx issuance
In what cases, dependent tx failed to be issued, so we need another tx issuance to trigger the tx issue
There was a problem hiding this comment.
If the user is issuing virtuous txs - verification will never fail. However, I didn't want to just have the node crash (or fall into an infinite loop) in this situation... So instead I dropped the tx and logged a warning.
In all likelihood - if one tx is dropped they all will be.
There was a problem hiding this comment.
... didn't want .. or fall into an infinite loop
Oh makes sense.
Co-authored-by: abenegia <alberto.benegiamo@gmail.com> Co-authored-by: Aaron Buchwald <aaron.buchwald56@gmail.com> Co-authored-by: Darioush Jalali <darioush.jalali@avalabs.org> Co-authored-by: Manthan Dave <manthanhd@live.com>
Why this should be merged
The X-chain mempool post Cortina does not allow dependent transactions to be included. For example:
The mempool disallows this to avoid mempool DoSes. However, the wallet API is explicitly designed to enable issuance of dependent txs.
How this works
Honors the mempool requirement of only having no dependent txs while making the API seem like there are dependent txs in the mempool. In the example above, Tx A will be issued into the mempool. If Tx B is then issued while Tx A is still processing, Tx B will be enqueued until Tx A is accepted. After Tx A is accepted, Tx B will be issued into the mempool.
This is a fairly minimal implementation that does not attempt to parallelize independent txs.
How this was tested
Issued many concurrent txs onto Fuji