-
Notifications
You must be signed in to change notification settings - Fork 427
Open
Labels
Take a Friday Leave a FridayStomp the Bugs, Without Much CommitmentStomp the Bugs, Without Much Commitment
Description
In our current implementation of Persist::archive_persisted_channel we first read the monitor, write it at the archive location and finally lazily remove the monitor to 'move' it to the archive. This is fine, except that a lazy remove isn't guaranteed to finish if we encounter a persistence failure or happen to restart. This means that we could end up in a situation with the channel monitor at both, the original and the archive location until the call to archive_fully_resolved_channel_monitors succeeds once.
All of this is fine, but I think we should clarify the docs:
- Currently the
Persist::archive_persisted_channeldocs state "Prevents the channel monitor from being loaded on startup.". We might want to clarify that this is not true if above mentioned scenario occurs. - We should give users guidance how to handle this case, i.e., which monitor a user might want to restore from if they need it.
- We should mention that any custom implementations of
Persist::archive_persisted_channelneed to be idempotent, i.e., need to be able to be run multiple times without erroring if the monitor is already present at the archive location.
Metadata
Metadata
Assignees
Labels
Take a Friday Leave a FridayStomp the Bugs, Without Much CommitmentStomp the Bugs, Without Much Commitment