New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doc Clarity: Persist ChannelMonitors and MonitorUpdates sequentially #2992
base: main
Are you sure you want to change the base?
Conversation
Clarified in documentation that users must persist `ChannelMonitor`s and `ChannelMonitorUpdate`s in sequential order, even more so when using async persistence.
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2992 +/- ##
==========================================
+ Coverage 89.26% 91.08% +1.82%
==========================================
Files 118 117 -1
Lines 96534 109344 +12810
Branches 96534 109344 +12810
==========================================
+ Hits 86167 99600 +13433
+ Misses 7872 7663 -209
+ Partials 2495 2081 -414 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't true, though. We don't require it, but have recommended it as it works around some current bugs that we intend to fix.
If we recommend it to clients, isn't it better to have it as part of documentation? Isn't it possible to write the latest monitor update first and then overwrite it with an out-of-date ChannelMonitor if the writes end up being out-of-order? |
It doesn't make the async persistence in general "safe". We can't reasonably enumerate all the things users have to be aware of when doing async persistence, because we also don't know all of those things. I'm not sure that listing one example is worth it or if it just gives people a false sense of security (at the cost of a ton of extra code complexity on the implementation end). We should focus on fixing the issues, really, IMO.
For an individual monitor, indeed, we care about consistency - the latest one has to be the one we have on disk, but of course if the user is persisting the updates then they can go in any order, we just have to replay all of them in order on reload. |
I was talking about full channelMonitor persists resulting from monitor-updates. |
Ah, okay, yea, I guess we can specify that. ISTM we should probably do that in the |
The change is already in
Even for MonitorUpdatePartial persist, we ideally want them to be in order. If we write update_id .. 7, 8, 10 and don't write update_id 9. Even if we remove MUP from the picture. It might be troublesome for multi-device as well, device-1 saved update-10, device-2 saved update-9, now this state can't be resolved. Overall i see multiple things that can go wrong or are just complicated with out-of-order writes for partial-monitor-updates as well. |
Uhhhhhh, right. Not sure what I meant.
These are separate things, though. The
Not strictly, no, but we should document what to do - the |
Clarified in documentation that users must persist
ChannelMonitor
s andChannelMonitorUpdate
s in sequential order, even more so when using async persistence.As part of #1792