Sending the same valid transaction twice (such as may happen under poor networking conditions) will cause one transaction to succeed and the other to fail.
This is expected behavior but the problem is that the resulting DB state is that the transaction "failed" despite it being properly included in the blockchain.
Fix:
Flip incorrect boolean result of a function
Note: I think this solution exposes a race condition because it follows a two step process:
1) Poll the DB to see the status of the transaction
2) If success, don't override. Otherwise override
However, what happens if after (1) returns that there is no "successful" transaction and before (2), the DB receives a "success" transaction.
Type of change
[~] 🐞 Bug fix (non-breaking change which fixes an issue)
[ ] 🛠 New feature (non-breaking change which adds functionality)
[ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
Description
Sending the same valid transaction twice (such as may happen under poor networking conditions) will cause one transaction to succeed and the other to fail. This is expected behavior but the problem is that the resulting DB state is that the transaction "failed" despite it being properly included in the blockchain.
Fix: Flip incorrect boolean result of a function
Note: I think this solution exposes a race condition because it follows a two step process: 1) Poll the DB to see the status of the transaction 2) If success, don't override. Otherwise override However, what happens if after (1) returns that there is no "successful" transaction and before (2), the DB receives a "success" transaction.
Type of change