Open akolotov opened 6 years ago
A preliminary fix can be found here: https://github.com/yrashk/parity-bridge/commit/19241a94e926f10247ddf4afee1458216d5fec78
@akolotov so in order to do this there are 2 strategies:
The scenario when a transaction was already sent and in txpool of the node and not included in the block yet. In this case both methods suggested above will return that new transaction with the same parameters could be sent but it is not true. And moreover such kind of approach could be considered as a workaround rather than fix of root cause.
What's our disposition on this?
I think that it could be closed as soon as #84 is merged.
The behaviour to re-establish IPC connection after parity re-run was introduced as part of fix for #22 (https://github.com/poanetwork/parity-bridge/commit/9c375cc89b810497cd700e73e39b89b0ab43c927).
But it caused appearance of minor regression: last set of transactions are being sent twice. Here is the logs from the foreign parity instance before it is killed:
The database file contains the following after that:
As soon as the parity instance is killed and run it produces the following logs:
and the database file contains:
These transactions are handled properly by the contracts that's why double-spend does not happen. But it increases expenses of bridge authorities by producing more transactions.