Skip to content
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

deps: use web-time instead of instant #5347

Merged
merged 27 commits into from
Jun 8, 2024

Conversation

dariusc93
Copy link
Member

Description

See sebcrozet/instant#52

Notes & open questions

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this Darius! Only one remark

core/Cargo.toml Outdated Show resolved Hide resolved
Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dariusc93 dariusc93 marked this pull request as ready for review May 15, 2024 03:02
Copy link
Contributor

@zvolin zvolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is also a usage of std::time in protocols/kad/src/kbucket.rs and misc/memory-connection-limits/src/lib.rs that should be replaced with wasm-compatible time implementation. Could you handle those in scope of this PR?

@dariusc93
Copy link
Member Author

There is also a usage of std::time in protocols/kad/src/kbucket.rs and misc/memory-connection-limits/src/lib.rs that should be replaced with wasm-compatible time implementation. Could you handle those in scope of this PR?

Hi. In kbucket.rs, Instant is used in the test so while we could change it to use web-time, it would not affect anything unless we want to try running test in wasm environment so I could make the change there. For memory-connection-limits, that crate is not compatible with wasm due to memory-stats not supporting wasm (though might be possible in the future - see Arc-blroth/memory-stats#1) so it would not be required to make changes there.

@zvolin
Copy link
Contributor

zvolin commented May 15, 2024

The issue with kbucket is that it's inner modules use use super::*; and leaks std::time into themselves like here. This isn't easy to spot because that wildcard import, ideally it should be removed too to prevent such surprises in future

@dariusc93
Copy link
Member Author

The issue with kbucket is that it's inner modules use use super::*; and leaks std::time into themselves like here. This isn't easy to spot because that wildcard import, ideally it should be removed too to prevent such surprises in future

Nice catch on that!

@zvolin
Copy link
Contributor

zvolin commented May 15, 2024

sorry for the offtop, but do you happen to know if there is any plan for the release which will include this? Or maybe some backport for 0.53? It crashes our node occasionally and since we're on crates already I'd like to avoid git dependencies

@dariusc93
Copy link
Member Author

sorry for the offtop, but do you happen to know if there is any plan for the release which will include this? Or maybe some backport for 0.53? It crashes our node occasionally and since we're on crates already I'd like to avoid git dependencies

I can imagine a patch release can be done for majority of the crates here while others like kad may fall under 0.54. A PR could be done to backport the web-time change too

@zvolin
Copy link
Contributor

zvolin commented May 15, 2024

For memory-connection-limits, that crate is not compatible with wasm

mdns would not be compatible with wasm

By the way, I included those without checking if they indeed support wasm, but my thinking is that it doesn't hurt to add it, eventually it may end up being useful and it's probably much easier to maintain if every Instant usage happens through wasm compatible crate. You don't need to wonder 'should it work for wasm?' and rather you see Instant in PR then just check if it is through web-time.

Copy link
Contributor

mergify bot commented May 18, 2024

This pull request has merge conflicts. Could you please resolve them @dariusc93? 🙏

@jxs
Copy link
Member

jxs commented May 20, 2024

sorry @dariusc93 can you rebase again one last time?

@oblique
Copy link
Contributor

oblique commented Jun 7, 2024

So after some hours of investigation I found why CI was failing. The instant/wasm-bindgen is still needed to be defined in libp2p/Cargo.toml because two dependencies were still using it:

After the above PRs are merged and a new yamux is released, the CI will pass.

@dariusc93
Copy link
Member Author

So after some hours of investigation I found why CI was failing. The instant/wasm-bindgen is still needed to be defined in libp2p/Cargo.toml because two dependencies were still using it:

* `yamux` - Opened PR: [feat: Use `web-time` instead of `instant` rust-yamux#191](https://github.com/libp2p/rust-yamux/pull/191)

* `libp2p-tls` - This was a mistake in `Cargo.toml` which made the `libp2p-tls` to use `libp2p-core` only from crates.io. Opened a PR with a fix: [fix: Use `libp2p-tls` from workspace #5452](https://github.com/libp2p/rust-libp2p/pull/5452)

After the above PRs are merged and a new yamux is released, the CI will pass.

Interesting but good catch. Im curious on why there wasnt an error with yamux at runtime when it attempts to use Instant under usual wasm testing.

@oblique
Copy link
Contributor

oblique commented Jun 7, 2024

Im curious on why there wasnt an error with yamux at runtime when it attempts to use Instant under usual wasm testing.

I think because of these two reasons:

  • wasm_ping binary of interop-tests does not fetch any errors that might happen.
  • run_test_wasm function of interop-tests does not set console_error_on_panic hook, so even if you check browser's console, you will not see an error.

@oblique
Copy link
Contributor

oblique commented Jun 7, 2024

@jxs Isn't it better to update libp2p-yamux/Cargo.toml instead of just Cargo.lock?

@jxs
Copy link
Member

jxs commented Jun 7, 2024

@jxs Isn't it better to update libp2p-yamux/Cargo.toml instead of just Cargo.lock?

sorry Yianis, I did not understand, van you elaborate?

@oblique
Copy link
Contributor

oblique commented Jun 7, 2024

Now yamux dependency is only updated in Cargo.lock to the 0.13.3 version and user can still get the non-web-time one because Cargo.toml is not updated.

I'm saying we should do this change:

diff --git a/muxers/yamux/Cargo.toml b/muxers/yamux/Cargo.toml
index ddb942489..4d6d655e3 100644
--- a/muxers/yamux/Cargo.toml
+++ b/muxers/yamux/Cargo.toml
@@ -16,7 +16,7 @@ futures = { workspace = true }
 libp2p-core = { workspace = true }
 thiserror = "1.0"
 yamux012 = { version = "0.12.1", package = "yamux" }
-yamux013 = { version = "0.13.1", package = "yamux" }
+yamux013 = { version = "0.13.3", package = "yamux" }
 tracing = { workspace = true }

 [dev-dependencies]

Copy link
Contributor

mergify bot commented Jun 8, 2024

This pull request has merge conflicts. Could you please resolve them @dariusc93? 🙏

@jxs jxs force-pushed the refactor/web-time-switch branch 2 times, most recently from bcd8e51 to 9f95ecb Compare June 8, 2024 01:12
@jxs jxs changed the title feat: use web-time instead of instant deps: use web-time instead of instant Jun 8, 2024
@jxs jxs force-pushed the refactor/web-time-switch branch from 9f95ecb to ed0ce1a Compare June 8, 2024 01:22
@jxs
Copy link
Member

jxs commented Jun 8, 2024

Now yamux dependency is only updated in Cargo.lock to the 0.13.3 version and user can still get the non-web-time one because Cargo.toml is not updated.

I'm saying we should do this change:

diff --git a/muxers/yamux/Cargo.toml b/muxers/yamux/Cargo.toml
index ddb942489..4d6d655e3 100644
--- a/muxers/yamux/Cargo.toml
+++ b/muxers/yamux/Cargo.toml
@@ -16,7 +16,7 @@ futures = { workspace = true }
 libp2p-core = { workspace = true }
 thiserror = "1.0"
 yamux012 = { version = "0.12.1", package = "yamux" }
-yamux013 = { version = "0.13.1", package = "yamux" }
+yamux013 = { version = "0.13.3", package = "yamux" }
 tracing = { workspace = true }

 [dev-dependencies]

ah right, thanks!

@jxs jxs added the send-it label Jun 8, 2024
@mergify mergify bot merged commit f54423a into libp2p:master Jun 8, 2024
72 checks passed
@jxs
Copy link
Member

jxs commented Jun 8, 2024

thanks for the initiative @dariusc93 and @oblique for investing time into debugging <3

@oblique oblique mentioned this pull request Jun 8, 2024
4 tasks
TimTinkers pushed a commit to unattended-backpack/rust-libp2p that referenced this pull request Sep 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants