Implement KVStore for TestStore#4069
Conversation
|
👋 Thanks for assigning @joostjager as a reviewer! |
e636a74 to
6246c04
Compare
6246c04 to
7faae86
Compare
|
|
||
| /// Async events processor that is based on [`process_events_async`] but allows for [`KVStoreSync`] to be used for | ||
| /// synchronous background persistence. | ||
| pub async fn process_events_async_with_kv_store_sync< |
There was a problem hiding this comment.
Hmm, not quite sure I understand why we want to drop this? ldk-node might not use it, but I imagine some others might? Its the equivalent of our previous async BP loop and keeping it makes upgrades easier for those who might not want to switch to partial-async-kvstore immediately?
There was a problem hiding this comment.
IMO it's a very odd middleground API that was introduced when the KVStoreSyncWrapper wasn't public. I fear users might find it confusing, and just using KVStoreSyncWrapper when needed seems way more consistent (as they'd already need to do that for some of the other types they'd hand into that method anyways).
There was a problem hiding this comment.
No comment. It's so little code that I think it's fine either way.
There was a problem hiding this comment.
IMO we should prefer users not use KVStoreSyncWrapper directly. The docs even explicitly say "It is not necessary to use this type directly." (and I feel like we should #[doc(hidden)] it?).
There was a problem hiding this comment.
Hmm, but at least in LDK Node using KVStoreSyncWrapper was unavoidable. I can drop the drop commit if you insist, but IMO it's a pretty awkward confusing API.
There was a problem hiding this comment.
Now dropped the drop commit since you prefer to keep it.
lightning/src/util/test_utils.rs
Outdated
| } | ||
| } | ||
|
|
||
| impl KVStore for TestStore { |
There was a problem hiding this comment.
I wonder if we shouldn't actually make these async? eg write the returned future to require two polls or something? Maybe its not worth it but seems like we should consider it. It feels a bit weird to have the test implementation do something that no real implementation should do.
There was a problem hiding this comment.
Alright, now added a fixup to do just that.
There was a problem hiding this comment.
Now force-pushed a further simplification, also allowing to drop the 'splitting' commit.
There was a problem hiding this comment.
Oh I like this double poll thing for testing. A bit too fake otherwise.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4069 +/- ##
==========================================
- Coverage 88.39% 88.34% -0.05%
==========================================
Files 177 177
Lines 131314 131922 +608
Branches 131314 131922 +608
==========================================
+ Hits 116069 116550 +481
- Misses 12596 12708 +112
- Partials 2649 2664 +15
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
lightning/src/util/test_utils.rs
Outdated
| let secondary_namespace = secondary_namespace.to_string(); | ||
| let key = key.to_string(); | ||
| let inner = Arc::clone(&self.inner); | ||
| Box::pin(async move { |
There was a problem hiding this comment.
Before returning this, I think we need to record the order?
There was a problem hiding this comment.
Or spawn_blocking and await?
There was a problem hiding this comment.
Or just call it because it isn't actually blocking?
There was a problem hiding this comment.
I don't think so, as it calls through to the inner Mutex? Ah, actually, now that we made it actually async as of #4069 (comment), we might need to?
There was a problem hiding this comment.
Or just call it because it isn't actually blocking?
You mean actually async? It is now, so we might need to do the whole write-tracking thing now..
There was a problem hiding this comment.
Nevermind, I think now that we retrieve the result sync again (while acquiring the inner Mutex), we should be good ordering-wise?
There was a problem hiding this comment.
Yes I think it's good now
There was a problem hiding this comment.
This has regressed again - its no longer correct. You should be able to drop the second-to-last commit and just do the actual operation sync and then return a future of the result.
There was a problem hiding this comment.
This has regressed again
Yes, I explicitly asked you whether to revert to this version though? So you don't want the intial version, but the intermediate version that implements the more complicated future logic, but doens't require polling twice. Okay.
There was a problem hiding this comment.
This has regressed again - its no longer correct. You should be able to drop the second-to-last commit and just do the actual operation sync and then return a future of the result.
Pushed another fully-sync-under-the-hood variant. Let me know if that's the right amount of regression.
7faae86 to
3ef76a5
Compare
3ef76a5 to
9df68fc
Compare
9df68fc to
3dc60fd
Compare
joostjager
left a comment
There was a problem hiding this comment.
I understand this is going to be used in ldk-node, but I don't think any of the async code is hit in ldk itself. It's basically dead code within that scope. Test coverage of test code is maybe a bit over the top?
|
|
||
| /// Async events processor that is based on [`process_events_async`] but allows for [`KVStoreSync`] to be used for | ||
| /// synchronous background persistence. | ||
| pub async fn process_events_async_with_kv_store_sync< |
There was a problem hiding this comment.
No comment. It's so little code that I think it's fine either way.
lightning/src/util/test_utils.rs
Outdated
| let secondary_namespace = secondary_namespace.to_string(); | ||
| let key = key.to_string(); | ||
| let inner = Arc::clone(&self.inner); | ||
| Box::pin(async move { |
There was a problem hiding this comment.
Yes I think it's good now
lightning/src/util/test_utils.rs
Outdated
| } | ||
| } | ||
|
|
||
| impl KVStore for TestStore { |
There was a problem hiding this comment.
Oh I like this double poll thing for testing. A bit too fake otherwise.
TheBlueMatt
left a comment
There was a problem hiding this comment.
There's a ton of room to make TestStore a better test, dunno if it has to happen here but if you have a minute it would be nice to make it a really good test.
3dc60fd to
cd28a16
Compare
|
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
cd28a16 to
c47ca84
Compare
c47ca84 to
444f408
Compare
|
Now reverted back to the initial approach 444f408. |
KVStore for TestStore, drop process_events_async_with_kv_store_syncKVStore for TestStore
|
Seems CI error is pre-existing? |
joostjager
left a comment
There was a problem hiding this comment.
When reverting, did this also undo the changes that followed from #4069 (comment)?
I think currently the order is lost again?
.. to be easier reusable by different trait implementations.
We implement the async `KVStore` trait for `TestStore`. This is mostly useful in LDK Node tests, where we use `TestStore` and we now require all stores to implement both variants.
444f408 to
012bb7a
Compare
|
Pushed another simplified fully-sync variant. Let me know if that works for you guys. |
|
This is now quite trivial, just gonna land it. |
We implement the async
KVStoretrait forTestStore. This is mostly useful in LDK Node tests, where we useTestStoreand we now require all stores to implement both variants.Moreover, we drop the Frankenstein-esqueprocess_events_async_with_kv_store_syncwhich won't be necessary anymore for LDK Node.