Feat: Add system-wide stream handler unregister method.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 624
- Forks
- 256
- Avg merge
- 1d 34m
- Merged PRs (30d)
- 47
Description
Summary
py-libp2p supports registering protocol stream handlers via set_stream_handler, but does not provide a guaranteed, system-wide way to unregister them.
This creates inconsistent service lifecycle behavior across modules.
Motivation
We need lifecycle symmetry for stream protocols in existing service lifecycle methods:
- service startup path should register handler(s)
- service shutdown path should unregister handler(s).
Without a standard unregister API, services currently use module-specific workarounds, which makes behavior inconsistent and harder to reason about on long-running hosts.
Current state
Core interfaces currently expose registration but not guaranteed removal:
No required remove_stream_handler / remove_handler contract exists at those interface levels.
Existing workaround patterns
-
Flags-only stop (service marked stopped, handler still registered)
- Bitswap stop path:
link
- Bitswap stop path:
-
Empty handler replacement as pseudo-unregister
- DCUtR sets an
empty_handler:
link
- DCUtR sets an
-
Optional unregister with fallback if method is missing
- Relay protocol tries
remove_stream_handler, falls back onAttributeError:
link
- Relay protocol tries
Proposed change (stream scope only)
- Add interface methods:
IHost.remove_stream_handler(protocol_id: TProtocol) -> NoneIMultiselectMuxer.remove_handler(protocol: TProtocol) -> None
- Implement in core:
BasicHost.remove_stream_handler(...)delegates to multiselectMultiselect.remove_handler(...)removes the protocol from handler map
- Service migration (follow-up in same or separate PRs):
- Update services that register handlers to unregister on stop/teardown
(perf,bitswap,kad_dht,relay/DCUtR, etc.)
Expected impact
- Consistent register/unregister semantics for stream protocols during service startup/shutdown
- Fewer ad-hoc unregister workarounds
- Cleaner behavior for long-lived hosts and protocol restarts
Are you planning to do it yourself in a pull request ?
yes
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the IHost and IMultiselectMuxer contracts in libp2p/abc.py, then locate BasicHost and Multiselect implementations. Confirm that BasicHost delegates removal and Multiselect removes the protocol from its handler map, using the listed bitswap, DCUtR, relay, perf, and kad_dht lifecycle paths as migration context. Done means the interfaces and core implementations provide the removal API with consistent stream-handler teardown semantics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100