[Consensus 2.0] update Clock to use the tokio Instant
Description
Swapping the std::time::Instant with the tokio::time::Instant for consistency across the Consensus crate.
The caveat here is that the simtest framework will by default try to run the #[test] tests where a tokio reactor is not running. Since the Context now uses tokio components (Instant) the simtest framework starts complaining with errors:
there is no reactor running, must be called from the context of a Madsim runtime
after talking to @mystenmark it looks like there aren't too many ways to bypass this. On this PR I've just converted all the #[test] to #[tokio::test] as in this case simtests framework won't attempt to run them at all . An alternative would be to tag them as #[cfg_attr(msim, ignore)]. Let's evaluate at this point how important is for us to use tokio::time::Instant and worth adding this implicit constraint to our tests.
Test plan
How did you test the new or updated feature?
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.
- [ ] Protocol:
- [ ] Nodes (Validators and Full nodes):
- [ ] Indexer:
- [ ] JSON-RPC:
- [ ] GraphQL:
- [ ] CLI:
- [ ] Rust SDK:
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| sui-docs | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Apr 26, 2024 0:50am |
3 Ignored Deployments
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| multisig-toolkit | ⬜️ Ignored (Inspect) | Visit Preview | Apr 26, 2024 0:50am | |
| sui-kiosk | ⬜️ Ignored (Inspect) | Visit Preview | Apr 26, 2024 0:50am | |
| sui-typescript-docs | ⬜️ Ignored (Inspect) | Apr 26, 2024 0:50am |
The tests you switched from #[test] to #[tokio::test] were not simtests anyways so we don't lose any additional testing that simtest provides running them or am I missing something?
Yes @arun-koshy those weren't simtests and we shouldn't lose any sort of coverage from that perspective
@akichidis heads up - we had to revert this in suspicion it is blocking CI: https://github.com/MystenLabs/sui/commit/3d0bc68de89c057407b8361ea72a8b9457d98a4a