-
Couldn't load subscription status.
- Fork 115
Asyncify test suite and reintroduce VSS-internal runtime #670
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
Asyncify test suite and reintroduce VSS-internal runtime #670
Conversation
.. as we're about to `cargo test` anyways.
.. some of the `ReadFailed` cases didn't log why they failed. Here we fix that oversight.
|
👋 Thanks for assigning @joostjager as a reviewer! |
f817f78 to
141f186
Compare
|
🔔 1st Reminder Hey @joostjager! This PR has been waiting for your review. |
e6e2073 to
584fff6
Compare
|
Now added changes reintroducing a secondary runtime internal to |
6d3a774 to
eedfb12
Compare
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.
PR could have been split up in independent changes, but perhaps too late now.
The whole rust async situation is so painful. It really seems to get to the point - if it wasn't already there - of being a true velocity killer.
eedfb12 to
dba502d
Compare
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.
Addressed remaining comments.
300e9bb to
4622fb1
Compare
|
CI failure is unrelated: #679 |
4622fb1 to
e4f3ba0
Compare
|
Addressed pending feedback. @joostjager let me know if I can squash. |
Given we regularly run into issues arising from mixing sync and async contexts, we here simplify our `EventQueue` implementation by avoiding to use `Condvar::wait_while` (which parks the current thread) and rather simply us `block_on` on our `next_event_async` method.
.. as LDK Node is moving towards a more `async` core, it starts to make sense to switch our test suite over to be `async`. This change should make our CI more efficient (as not every node will spawn its independent runtime, but we just have one runtime per test created) and also makes sure we won't run into any edge cases arising from blocking test threads that are executing other async tasks.
Since it seems to make a difference to `tokio` (see https://docs.rs/tokio/latest/tokio/time/fn.timeout.html#panics) we make sure the futures are always put in an `async` closure.
In order to avoid the recently, discovered blocking-task-deadlock (in which the task holding the runtime reactor got blocked and hence stopped polling VSS write tasks), we where re-introduce an internal runtime to the `VssStore`, on which we spawn the tasks, while still using `block_on` of our regular runtime for async-sync conversions. This also finally fixes our VSS CI.
.. we previously avoided running some tests which turned out to be broken.
e4f3ba0 to
8cad63b
Compare
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.
Remaining questions answered offline and summarized in threads. LGTM
As we're looking to move to a more
async-friendly API over time (which would allow us to drop the dependency on theKVStoreSyncimplementation entirely), we here make a few prefactors and minor improvements that move in that direction.Most notably, we switch to have our tests run in async contexts, which also should make them more efficient as not every node will spawn its own runtime, but rather reuse the one runtime spawned for each test case.
Moreover, we reintroduce a secondary runtime internal to
VssStorein order to fix the blocking issue we recently hit in our CI. Additionally, we found that not all tests cfg-gated undervss_testwere being run, so we fix these test cases and have them run in CI.