-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIM-BE Some transactions in the consensus queue get duplicated, potentially resulting in stuck processing #502
Comments
Is this expected @cristiam86 @AgustinRamiroDiaz ? Otherwise,see linked branch for a fix proposal. The idea would be to avoid duplicates by checking if the tx ID exists in the queue first, and keeping track of processed txs. |
Oh, yes, the transaction shouldn't be re-inserted in the queue. This could be fixed when we implement the nonce, it is the purpose of that field |
This is highly related to #387. There was a patch done to print the
This is an almost perfect solution, but there's a small race condition that could happen where:
It would be a great improvement for 99% of the cases, so maybe it's a good idea to also add that patch To make it 100% reliable I think we'll probably need to add some kind of synchronization between the 2 threads, like a lock or something |
We should implement the same blockchain approach, if there is a transaction with that nonce, it get's rejected. |
When submitting many transactions, it happens that they get stuck on pending.
When checking the backend logs, I see some errors:
~ ~ ~ ~ ~ TRANSACTION ALREADY IN PROCESS
And when printing the queued tx IDS and status in the backend, I see that many transactions apparently get added multiple times to the queue, not sure if this is expected:
Step to reproduce:
Restarting the backend clears the clone-filled queue and gets the process unstuck.
The text was updated successfully, but these errors were encountered: