feat: remove async_std support in TCP crate #5955

gitToki · 2025-03-25T13:19:13Z

crate to update:
swarm, mDNS, and the transports TCP, QUIC and DNS.

dariusc93

Thanks. Left a couple of comments

dariusc93 · 2025-03-25T13:31:41Z

transports/tcp/Cargo.toml

 async-io = ["dep:async-io", "if-watch/smol"]
+default = ["tokio"]


We probably should not have it default to tokio right now since it would require disabling default features to enable the needed feature

Ok, will correct next commit

dariusc93 · 2025-03-25T13:32:47Z

transports/tcp/src/lib.rs

+//! This crate provides a [`async_io::Transport`] (deprecated) and [`tokio::Transport`],
+//! which implement the [`libp2p_core::Transport`] trait for use as a
+//! transport with `libp2p-core` or `libp2p-swarm`.


Though the comment is modified, it is also duplicated from above.

jxs

Can we not soft deprecate and just hard deprecate? CC @elenaf9 @dariusc93

elenaf9 · 2025-03-26T00:32:22Z

Can we not soft deprecate and just hard deprecate? CC @elenaf9 @dariusc93

@gitToki initially did that, but I asked for a soft deprecation. I think a soft deprecation makes sense here because we might still have users that use async_std. It would a) give them time to object before we do a hard removal and b) offer a transition period for them.

Any specific reason why you'd prefer a direct removal @jxs?

dariusc93 · 2025-03-26T00:39:16Z

Can we not soft deprecate and just hard deprecate? CC @elenaf9 @dariusc93

Would there be any reason to suddenly do a hard deprecation vs soft? Imo, I think we should do a soft (though I am not against a hard one) to give users a time to switch or figure out plans on migration (or supporting the executor themselves for the respected protocols and utils).

jxs · 2025-04-03T15:06:03Z

Hi!

Any specific reason why you'd prefer a direct removal @jxs?

the reason is more work, double the PR's for something that has been declared as unmaintained, I feel redundant to have a version for users to remove their usage when they probably are already removing, added to the fact that I have seen soft deprecations lost in time.
But if you two agree that we should do soft I cede :)

gitToki · 2025-04-13T19:19:07Z

updated, should be good. @dariusc93 please let me know if everything look good to you

elenaf9 · 2025-04-17T08:59:39Z

transports/tcp/src/lib.rs

@@ -47,8 +47,6 @@ use libp2p_core::{
    multiaddr::{Multiaddr, Protocol},
    transport::{DialOpts, ListenerId, PortUse, TransportError, TransportEvent},
 };
-#[cfg(feature = "async-io")]
-pub use provider::async_io;
 #[cfg(feature = "tokio")]
 pub use provider::tokio;
 use provider::{Incoming, Provider};


@jxs @dariusc93 based on the discussion in #5935 (comment), should we make the Incoming and Provider traits public to allow a downstream implementation?

In the other affected crates (libp2p-quic, libp2p-dns, etc.) the Provider traits are already public.

Actually, we aren't really consistent on this. In libp2p-mdns for example the Provider trait is also private.

Still, I think we should make them public in all crates.

yeah makes sense to me, and possibly isolate them so they aren't duplicated right?

yeah makes sense to me, and possibly isolate them so they aren't duplicated right?

Yes good idea. But let's do that in a follow-up PR.

mergify · 2025-06-04T13:43:00Z

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

muxers/mplex/Cargo.toml

transports/tcp/src/lib.rs

gitToki · 2025-06-05T16:43:13Z

Is it good to you now @elenaf9 ? 🫡

elenaf9

Thank you for the follow-up @gitToki

protocols/dcutr/CHANGELOG.md

elenaf9 · 2025-06-05T16:54:11Z

protocols/request-response/src/cbor.rs


    use crate::{cbor::codec::Codec, Codec as _};

-    #[async_std::test]
+    #[tokio::test]
    async fn test_codec() {
        let expected_request = TestRequest {
            payload: "test_payload".to_string(),


Changing the request-response tests to use tokio is out of scope for this PR but blocked by it. There is a pending PR #5857 for this, that is blocked by failing tests. Would be interested in helping on that PR?

Yes sure I will try to take a look

transports/tcp/src/lib.rs

elenaf9 · 2025-06-05T16:56:59Z

transports/websocket/src/lib.rs

+    #[tokio::test]
+    async fn dialer_connects_to_listener_ipv4() {
        let a = "/ip4/127.0.0.1/tcp/0/ws".parse().unwrap();
-        futures::executor::block_on(connect(a))
+        connect(a).await
    }

-    #[test]
-    fn dialer_connects_to_listener_ipv6() {
+    #[tokio::test]
+    async fn dialer_connects_to_listener_ipv6() {
        let a = "/ip6/::1/tcp/0/ws".parse().unwrap();
-        futures::executor::block_on(connect(a))
+        connect(a).await
    }

-    fn new_ws_config() -> Config<tcp::async_io::Transport> {
-        Config::new(tcp::async_io::Transport::new(tcp::Config::default()))
+    fn new_ws_config() -> Config<tcp::tokio::Transport> {
+        Config::new(tcp::tokio::Transport::new(tcp::Config::default()))
    }


Same here. This should be a separate PR, and the current PR should only be merged afterwards.

Are you OK if I open a new PR for websocket ? I already made the change in a new branch (it was fast), available here: master...gitToki:rust-libp2p:websocket

Sure, thanks!

mergify · 2025-06-09T09:56:31Z

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

migrate from async-std to tokio, asked before [here](#5955 (comment)) Pull-Request: #6054.

deprecate async_std support in TCP crate

d9d98ae

dariusc93 changed the title ~~chore!: deprecate async_std support in TCP crate~~ chore: deprecate async_std support in TCP crate Mar 25, 2025

dariusc93 reviewed Mar 25, 2025

View reviewed changes

gitToki added 2 commits March 25, 2025 14:38

tokio not default

d631545

Merge branch 'master' into TCP

1beb916

jxs reviewed Mar 25, 2025

View reviewed changes

Merge branch 'master' into TCP

5147a19

Merge branch 'master' into TCP

e3a4271

gitToki and others added 5 commits April 13, 2025 20:51

Merge branch 'libp2p:master' into TCP

bbe06f2

update tcp crate

8218394

update tcp crate

f8e5843

update lib rs

3bf2111

re-update lib rs

68856ee

elenaf9 reviewed Apr 17, 2025

View reviewed changes

This was referenced Apr 17, 2025

feat: deprecate async_std support in DNS crate #5959

Draft

feat: remove async_std support in QUIC crate #5954

Merged

Toki added 2 commits April 29, 2025 23:54

update TCP crate

314b972

async ref in websocket toml

096b242

jxs changed the title ~~chore: deprecate async_std support in TCP crate~~ feat: deprecate async_std support in TCP crate Jun 4, 2025

elenaf9 changed the title ~~feat: deprecate async_std support in TCP crate~~ feat: remove async_std support in TCP crate Jun 4, 2025

gitToki and others added 5 commits June 4, 2025 17:21

Merge branch 'master' into TCP

bee4d48

update test / cargo

822c060

changelog

0c7951e

update changelog

09f8ede

update changelog / swarm test version / test

bb8d7fa

fmt

1f6883c

elenaf9 reviewed Jun 4, 2025

View reviewed changes

muxers/mplex/Cargo.toml Outdated Show resolved Hide resolved

elenaf9 reviewed Jun 4, 2025

View reviewed changes

transports/tcp/src/lib.rs Outdated Show resolved Hide resolved

Toki added 2 commits June 5, 2025 17:35

update test - swarm - changelog

79aec61

update cargo websocket / fmt

2c2a167

elenaf9 reviewed Jun 5, 2025

View reviewed changes

Toki added 3 commits June 7, 2025 18:22

remove version bump and remove curly brackets

61a1138

undo websocket

4b38073

libp2p websocket v

8a9d2d2

gitToki mentioned this pull request Jun 9, 2025

chore(websocket): migrate test from async-std to tokio #6054

Merged

4 tasks

mergify bot pushed a commit that referenced this pull request Jun 10, 2025

chore(websocket): migrate test from async-std to tokio

00e0d29

migrate from async-std to tokio, asked before [here](#5955 (comment)) Pull-Request: #6054.

		async-io = ["dep:async-io", "if-watch/smol"]
		default = ["tokio"]

feat: remove async_std support in TCP crate #5955

Are you sure you want to change the base?

feat: remove async_std support in TCP crate #5955

Uh oh!

Conversation

gitToki commented Mar 25, 2025

Uh oh!

dariusc93 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jxs left a comment

Choose a reason for hiding this comment

Uh oh!

elenaf9 commented Mar 26, 2025

Uh oh!

dariusc93 commented Mar 26, 2025

Uh oh!

jxs commented Apr 3, 2025 • edited by elenaf9 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gitToki commented Apr 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mergify bot commented Jun 4, 2025

Uh oh!

Uh oh!

Uh oh!

gitToki commented Jun 5, 2025

Uh oh!

elenaf9 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gitToki Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mergify bot commented Jun 9, 2025

Uh oh!

Uh oh!

jxs commented Apr 3, 2025 •

edited by elenaf9

Loading

gitToki Jun 7, 2025 •

edited

Loading