Problem: potential loss of database updates #84
Assignees
Comments
yrashk
added a commit
to yrashk/parity-bridge
that referenced
this issue
May 26, 2018
chance of loss of database updates that would cause it to redo transactions it already did. Let's say we've got some database updates through deposit relaying: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L164-L165 Then, during relaying withdrawals, an error happened: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L171-L172 This means that we won't reach https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L185-L193 to save the result. Also, in a similar vein, if one of these streams was to end (`Ready(None)`) we'd experience a similar loss of updates: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/macros.rs#L5 Solution: refactor bridge into two streams, splitting responsibilities One stream (`BridgeEventStream`) returns `BridgeChecked` and the other (`Bridge`) writes those checks down to the database. This way we're not accumulating chcecks before we serialize them, risking not serializing them at all in the event of an unrelated error. Fixes omni#84
ghost
assigned 
noot
pushed a commit
to noot/poa-bridge
that referenced
this issue
Jul 18, 2018
explain current functionality, next steps and relay flows in readme
noot
pushed a commit
to noot/poa-bridge
that referenced
this issue
Jul 18, 2018
chance of loss of database updates that would cause it to redo transactions it already did. Let's say we've got some database updates through deposit relaying: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L164-L165 Then, during relaying withdrawals, an error happened: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L171-L172 This means that we won't reach https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L185-L193 to save the result. Also, in a similar vein, if one of these streams was to end (`Ready(None)`) we'd experience a similar loss of updates: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/macros.rs#L5 Solution: refactor bridge into two streams, splitting responsibilities One stream (`BridgeEventStream`) returns `BridgeChecked` and the other (`Bridge`) writes those checks down to the database. This way we're not accumulating chcecks before we serialize them, risking not serializing them at all in the event of an unrelated error. Fixes omni#84
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The way the core bridge module is structured there's a non-zero chance of loss of database updates that would cause it to redo transactions it already did.
Let's say we've got some database updates through deposit relaying:
https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L164-L165
Then, during relaying withdrawals, an error happened:
https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L171-L172
This means that we won't reach https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/bridge/mod.rs#L185-L193 to save the result.
Also, in a similar vein, if one of these streams was to end (
Ready(None)) we'd experience a similar loss of updates: https://github.com/poanetwork/poa-bridge/blob/master/bridge/src/macros.rs#L5The text was updated successfully, but these errors were encountered: