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

Incompatibility between handle tsdoc and implementation #2928

Closed
wemeetagain opened this issue Jan 30, 2025 · 4 comments · Fixed by #2945 or #2944
Closed

Incompatibility between handle tsdoc and implementation #2928

wemeetagain opened this issue Jan 30, 2025 · 4 comments · Fixed by #2945 or #2944
Labels
good first issue Good issue for new contributors topic/docs Documentation

Comments

@wemeetagain
Copy link
Member

  • Version:
    all

  • Platform:
    all

  • Subsystem:
    registrar

Severity:

medium (due to blatantly incorrect documentation)

Description:

o The tsdoc says you can override the existing handler by calling handle. but turns out it is an error to override an existing handler.

I don't see why replacing a handler should be an error.

@wemeetagain wemeetagain added the need/triage Needs initial labeling and prioritization label Jan 30, 2025
@achingbrain
Copy link
Member

I don't see why replacing a handler should be an error

If you have two services that register a handler for the same protocol, it'd be a last-update-wins situation which (for example) would make the functionality of your node dependent on the order of the services defined in the service map.

One day some well-wisher decides to put them into alphabetical order and then things mysteriously start to break.

Throwing an error if a handler is already registered means you have to explicitly un-register a previously registered handler first - the expectation is that an attempt to register two handlers for the same protocol is probably an error.

The docs should be updated though.

@achingbrain achingbrain added good first issue Good issue for new contributors topic/docs Documentation and removed need/triage Needs initial labeling and prioritization labels Feb 3, 2025
@nflaig
Copy link

nflaig commented Feb 3, 2025

Throwing an error if a handler is already registered means you have to explicitly un-register a previously registered handler first - the expectation is that an attempt to register two handlers for the same protocol is probably an error.

the use case in Lodestar is that we have to update the handlers across hard forks, I am not sure about the internals of unhandle but since handle is async I am not sure it's safe to re-register handlers on the fly.

Maybe a flag to by pass the error and allow override?

@wemeetagain
Copy link
Member Author

unhandle+handle triggers self:peer:update which is not great because it will trigger identify-push which may have unintended consequences.

@achingbrain
Copy link
Member

achingbrain commented Feb 4, 2025

Maybe a flag to by pass the error and allow override?

A force flag sounds like a reasonable compromise. The user can opt-in if they know what they're doing then, and users that don't will still get the error message telling them they're doing something they might not realise they are doing.

achingbrain added a commit that referenced this issue Feb 6, 2025
Adds a `force` flag to `libp2p.handle` that means the method will
not throw if a handler already exists for the protocol being handled.

Fixes #2928
achingbrain added a commit that referenced this issue Feb 6, 2025
Adds a `force` flag to `libp2p.handle` that means the method will
not throw if a handler already exists for the protocol being handled.

Fixes #2928
achingbrain added a commit that referenced this issue Feb 6, 2025
Adds a `force` flag to `libp2p.handle` that means the method will
not throw if a handler already exists for the protocol being handled.

Fixes #2928
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good issue for new contributors topic/docs Documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants