Checkpoints: Handle persistence and restoration of data before a checkpoint
TheCharlatan opened this issue · 2 comments
Exiting the farcaster software during a running swap, but before it has been checkpointed, will result in the swap disappearing, but remaining in the trade history persistence. This could be confusing to users who are expecting to view the same swaps again when they re-start their software.
There are a couple of things we could do to mitigate, improve, or even solve this situation.
-
Add additional checkpoints. By adding checkpoints right after the Maker sends the reveal on the maker side, and right after the taker receives the reveal message, we can checkpoint before Bob's initial funding action. This allows us to at least restore to a state where the user can cleanly abort.
-
On startup we delete any dangling swap data from the database, this keeps the swap stats clean, and will make it look like the swap never happened.
-
On startup we move any dangling swap data from the in progress into the aborted state and then show the user that its swap has been aborted.
-
We treat any leftover swap data after startup as a separate category
In short after an in-person discussion choose option 3: On startup we move any dangling swap data from the in progress into the aborted state and then show the user that its swap has been aborted.
Additionally, once that is handled, add a swap id to the persisted funding addresses, then on startup retrieve the dangling swaps again and check if there is any remaining sweep-able balance for it, if it has a funding address.
Additionally, once that is handled, add a swap id to the persisted funding addresses, then on startup retrieve the dangling swaps again and check if there is any remaining sweep-able balance for it, if it has a funding address.
I'm feeling like sweeping here might lead to more confusion than it would help. We have a swap id now in the persisted addresses, so retrieving the relevant information after the fact is possible.