replace async_service with anyio_service

[Khwahish29]

What was wrong?

The codebase previously relied on a custom async_service implementation, which was no longer actively maintained and introduced unnecessary complexity. It made lifecycle management fragile and lacked support for modern async patterns and structured concurrency.
Issue #524

How was it fixed?

The legacy async_service implementation was fully replaced with a new design built using anyio, a well-supported, high-level async framework. This transition modernizes the service infrastructure and significantly improves reliability, maintainability, and task supervision.

Cute Animal Picture

[pacrob]

You don't need to edit the release notes directly. Create a newsfragment for each section you want to update with the original issue, e.g. 524.feature.rst, 524.docs.rst, etc. Newsfragments are then compiled into release notes with each release.

[Khwahish29]

I was facing the same issue as mentioned in #595 , while tinkering to solve it I accidentally committed the unnecessary changes, will revert them back, sorry for the confusion caused due to this

[mystical-prog]

hey @seetadev
I am assisting @Khwahish29 on this PR as it involves changes majorly around Gossipsub implementation, so I thought it would be a good idea to collaborate on this one.

[Khwahish29]

hey @seetadev I am assisting @Khwahish29 on this PR as it involves changes majorly around Gossipsub implementation, so I thought it would be a good idea to collaborate on this one.

Thanks for jumping in, @mystical-prog - really appreciate your support on this! Since the PR touches quite a bit on Gossipsub, it’s great to have your expertise here. I’ll continue driving this forward and loop you in wherever needed for the protocol-specific bits. Looking forward to refining this together! 🚀

[seetadev]

hey @seetadev I am assisting @Khwahish29 on this PR as it involves changes majorly around Gossipsub implementation, so I thought it would be a good idea to collaborate on this one.

@mystical-prog : Awesome :) great to hear.

Thank you so much for the initiative. This is indeed a major PR. Please open a discussion page and add developer documentation side by side, if convenient.

[mystical-prog]

I will add all the necessary documentation and references so that everyone remains in loop, looking to close this ASAP

[paschal533]

Hi @mystical-prog, How is the progress going? I will be fixing the failing tests in this PR from today and will keep you posted

[mystical-prog]

hey @paschal533
I believe @Khwahish29 has done a wonderful job in getting the basic structure ready, all that is left now is to fix CI and make sure that tests are passing !

[seetadev]

hey @paschal533 I believe @Khwahish29 has done a wonderful job in getting the basic structure ready, all that is left now is to fix CI and make sure that tests are passing !

@paschal533 : Completely agree with @mystical-prog. Wish to share that the key code commits are almost complete. Vraj and Khwahish have arrived at a good conclusion on the feature enhancement.

Wish to recommend you to bootstrap interop tests with JS-libp2p with focus on ping protocol. I'll be opening the issue and assigning it to you and Luca. On the same note, @mystical-prog authored ping protocol in cohort-1 and will be able to help arrive at a good conclusion on the issue.

@mystical-prog : Thank you for the update. Appreciate the initiative and efforts by you and @Khwahish29. I'll add you to the thread on interop tests between py-libp2p and js-libp2p with focus on ping protocol.

[Khwahish29]

hey @seetadev

we have identified an issue with anyio integration, due to a peer p2pclient's dependency of anyio being strictly less than 2.0.0, we are stuck with outdated anyio version, can you please guide on how to arrive at a solution which uses the latest anyio version and resolve p2pclient's dependency, we are currently blocked on this.

[seetadev]

hey @seetadev

we have identified an issue with anyio integration, due to a peer p2pclient's dependency of anyio being strictly less than 2.0.0, we are stuck with outdated anyio version, can you please guide on how to arrive at a solution which uses the latest anyio version and resolve p2pclient's dependency, we are currently blocked on this.

@Khwahish29 : Hi Khwahish. Thank you for sharing the issue.

We are facing similar kind of issues in pymultiaddrs too. Did share pointers and feedback with you.

I'll investigate possible resolutions and discuss with you and @mystical-prog soon.

Please check if a newer version of p2pclient exists that has relaxed or updated its anyio dependency (i.e., supports anyio>=2.0.0 or higher). If such a version exists, upgrading p2pclient directly should resolve the conflict.

If no such version exists, we may want to reach out to the maintainers or check open issues/PRs to see if there is any ongoing work in this direction.

We might want to update the package locally (we just did that for multiformats/pymultiaddrs) in case we are not getting the requisite support. In case of pymultiaddrs, the multiformats have agreed to let Py-libp2p dev team be the external maintainers of the repo.

@pacrob : Wish to have your thoughts, feedback and pointers on the above approach.

[pacrob]

It looks like a similar issue to pymultiaddrs, but not as complicated. The library - https://github.com/mhchia/py-libp2p-daemon-bindings - is in the personal repository of one of the original py-libp2p authors.

In order to move forward quickly, we can fork the repository and make changes to it, then update the dependency in py-libp2p to pull from that new fork instead of pypi. Since it is only a test dependency, I do not have any immediate security concerns.

We can then either:

• Contact @mhchia and ask for permission to take over the pypi project
• Publish our own fork (with credit) under a different name on pypi

It may also be worth investigating importing the code directly in to the py-libp2p testing utils (tests/utils). If the code is small enough, this might be simpler than maintaining a new repo.

[seetadev]

It looks like a similar issue to pymultiaddrs, but not as complicated. The library - https://github.com/mhchia/py-libp2p-daemon-bindings - is in the personal repository of one of the original py-libp2p authors.

In order to move forward quickly, we can fork the repository and make changes to it, then update the dependency in py-libp2p to pull from that new fork instead of pypi. Since it is only a test dependency, I do not have any immediate security concerns.

We can then either:

• Contact @mhchia and ask for permission to take over the pypi project
• Publish our own fork (with credit) under a different name on pypi

It may also be worth investigating importing the code directly in to the py-libp2p testing utils (tests/utils). If the code is small enough, this might be simpler than maintaining a new repo.

@pacrob : Thank you so much for your feedback, guidance and pointers. Appreciate your great support.

Absolutely agree with your assessment—this does feel similar to the situation with pymultiaddrs, but definitely more contained, especially given that it's scoped to test utilities. I appreciate you outlining multiple pragmatic paths forward.

Forking the original repository to unblock our current development sounds like a great immediate step. I’d be happy to collaborate with @mystical-prog , @Khwahish29 and @acul71 to help set that up and update the dependency in py-libp2p to point to the new fork. This gives us flexibility without delaying improvements or CI pipelines.

I also like that you've laid out longer-term options—particularly contacting @mhchia for PyPI publishing rights. That would keep things clean and centralized, but having a backup plan like publishing under a new name (with attribution) ensures we’re not blocked either way. I’ll look into the repository size and dependency usage to see if inlining the relevant code into tests/utils is feasible—it could indeed simplify maintenance if the logic is self-contained enough.

Thank you once again. We will go ahead with the fork + temporary dependency patch for now, and we can parallel-track the PyPI ownership or consolidation discussion. I can draft a short summary and ping @mhchia to check if they’re open to transferring ownership or collaborating on a shared solution.

Thanks again for helping move this forward efficiently—really appreciate your clear direction.