-
Notifications
You must be signed in to change notification settings - Fork 1.2k
refactor(swarm): remove deprecated inject calls #3264
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
Conversation
swarm-derive: remove inject methods from derive macro.
thomaseizinger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks for following up on that!
I think we can simplify some of this a bit. Let me know if you need more input :)
swarm/src/handler/either.rs
Outdated
| #[allow(deprecated)] | ||
| handler.inject_fully_negotiated_outbound(output, info) | ||
| (Either::Left(handler), EitherOutput::First(output), Either::Left(info)) => { | ||
| handler.on_connection_event(ConnectionEvent::FullyNegotiatedOutbound( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems weird that we need to match on the event here (line 174). I think it would be better if we added a
impl ConnectionEvent<EitherOutput, EitherOutput, Either, Either> { }block where we map the entire event into a Either<ConnectionEvent, ConnectionEvent> so you can directly dispatch the event to the left or the right handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that would be great. I tried:
impl<'a, R, L>
ConnectionEvent<
'a,
EitherUpgrade<SendWrapper<L::InboundProtocol>, SendWrapper<R::InboundProtocol>>,
EitherUpgrade<SendWrapper<L::OutboundProtocol>, SendWrapper<R::OutboundProtocol>>,
Either<L::InboundOpenInfo, R::InboundOpenInfo>,
Either<L::OutboundOpenInfo, R::OutboundOpenInfo>,
>
where
L: ConnectionHandler,
R: ConnectionHandler,
{}
but get that L and R are not constrained. I wonder if #3085 (comment) would have changed that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking something like e3480d2. It doesn't compile yet but maybe you can make it work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the lead Thomas, managed to make it work. Used Either::Left for AddressChange instead of the Result as it seemed more semantically accurate in the sense that it's not err, it just doesn't matter if it's either Left or Right for that variant, cause when matching on on_connection_event we still have the Either::Right . Ptal and see if you agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the lead Thomas, managed to make it work. Used
Either::LeftforAddressChangeinstead of theResultas it seemed more semantically accurate in the sense that it's not err, it just doesn't matter if it's eitherLeftorRightfor that variant, cause when matching onon_connection_eventwe still have theEither::Right. Ptal and see if you agree.
Yeah I wasn't sure about that one. I think one could argue it is an error because we couldn't unambiguously transpose it. Can we make it work with Result or is moving to Either::Left essential?
Alternatively, we could wrap it in another Either but that is a bit weird. If possible, I'd prefer the Result return type and some documentation on why it is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no you are right, documenting it informing that an Err can be because AddressChange isn't transposable makes sense to me, updated it :)
swarm/src/handler/select.rs
Outdated
| <Self as ConnectionHandler>::OutboundProtocol, | ||
| >, | ||
| ) { | ||
| match (info, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, I think we could make use of the same mapping function from above here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed, see if that's what you were expecting Thomas
mxinden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this.
| fn on_swarm_event(&mut self, _event: FromSwarm<Self::ConnectionHandler>) {} | ||
| fn on_swarm_event(&mut self, event: FromSwarm<Self::ConnectionHandler>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
| } | ||
|
|
||
| fn inject_fully_negotiated_inbound( | ||
| fn on_connection_event( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this change is breaking, right? Thus advocating for no changelog.
On a related note, shouldn't our CI have caught this? Shouldn't this have generated a deprecation warning and thus shouldn't CI have failed? Can you investigate this @jxs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this isn't a breaking change afaik, as they are only called by the Behaviour
On a related note, shouldn't our CI have caught this? Shouldn't this have generated a deprecation warning and thus shouldn't CI have failed?
good point, cargo doesn't trigger deprecation warning on the implementation, only on the invocation IRC, do we have any code triggering calls to the methods?
swarm/src/handler/either.rs
Outdated
| #[allow(deprecated)] | ||
| handler.inject_fully_negotiated_outbound(output, info) | ||
| (Either::Left(handler), EitherOutput::First(output), Either::Left(info)) => { | ||
| handler.on_connection_event(ConnectionEvent::FullyNegotiatedOutbound( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that would be great. I tried:
impl<'a, R, L>
ConnectionEvent<
'a,
EitherUpgrade<SendWrapper<L::InboundProtocol>, SendWrapper<R::InboundProtocol>>,
EitherUpgrade<SendWrapper<L::OutboundProtocol>, SendWrapper<R::OutboundProtocol>>,
Either<L::InboundOpenInfo, R::InboundOpenInfo>,
Either<L::OutboundOpenInfo, R::OutboundOpenInfo>,
>
where
L: ConnectionHandler,
R: ConnectionHandler,
{}
but get that L and R are not constrained. I wonder if #3085 (comment) would have changed that.
mxinden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the follow-ups.
| } | ||
|
|
||
| fn inject_fully_negotiated_inbound( | ||
| fn on_connection_event( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this change is breaking, right? Thus advocating for no changelog.
On a related note, shouldn't our CI have caught this? Shouldn't this have generated a deprecation warning and thus shouldn't CI have failed? Can you investigate this @jxs?
| - Replace `NetworkBehaviour` Derive macro deprecated `inject_*` method implementations | ||
| with the new `on_swarm_event` and `on_connection_handler_event`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entry was previously mistakenly in v0.31.0, right? I.e. we did not actually move to the on_ methods in swarm-derive in v0.31.0 as otherwise our non-breaking-change hack would not have worked, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah exactly, thanks for referring this Max.
mxinden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please trigger mergify once the above discussion with @thomaseizinger is resolved.
|
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
for ConnectionEvent and DialUpgradeError, to help when matching on them for Either and Select.
| S1OOI: Send + 'static, | ||
| S2OOI: Send + 'static, | ||
| { | ||
| fn transpose(self) -> Either<DialUpgradeError<S1OOI, S1OP>, DialUpgradeError<S2OOI, S2OP>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you split this out. I actually think it makes sense to split this out for all structs of ConnectionEvent. Can we reuse this as part of implementing the bigger transpose function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thanks :D but I did it because in some variants like ListenUpgradeError or AddressChange transpose doesn't win us anything as we have to call it for both Select variants. I updated the code implementing for the variants where it makes sense, ptal Thomas and see if it makes sense to you.
|
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
for the remaining ConnectionEvents that is useful to implement on.
to Result and document it.
swarm/src/handler/either.rs
Outdated
| ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | ||
| protocol: EitherOutput::First(protocol), | ||
| info: Either::Left(info), | ||
| }) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | ||
| FullyNegotiatedInbound { protocol, info }, | ||
| ))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | |
| protocol: EitherOutput::First(protocol), | |
| info: Either::Left(info), | |
| }) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | |
| FullyNegotiatedInbound { protocol, info }, | |
| ))), | |
| ConnectionEvent::FullyNegotiatedInbound(inner) => Ok(inner.transpose()), |
Does this work? Or do we have to call .map on it again or something?
It would be cool if we can express this transpose function somehow through the smaller ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't because Select's implementation uses SelectUpgrade whereas Either uses EitherUpgrade, do you have any idea how can we combine them in transpose? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can combine them for select and either because those are fundamentally different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, one of them is using EitherOutput which we need because Either doesn't implement AsyncRead + AsyncWrite.
See #2650.
|
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
|
@thomaseizinger submitted #3307 which started as fork from this one and also addresses some of the conversations here. Can we merge this one and continue there? I can also open an issue to address potential unresolved conversations. |
thomaseizinger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more comments, overall looks good to me!
swarm/CHANGELOG.md
Outdated
| - Add `estblished_in` to `SwarmEvent::ConnectionEstablished`. See [PR 3134]. | ||
|
|
||
| - Remove deprecated `inject_*` methods from `NetworkBehaviour` and `ConnectionHandler`. | ||
| see [PR 3260]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| see [PR 3260]. | |
| see [PR 3264]. |
Wrong issue reference :)
swarm/src/handler/either.rs
Outdated
| ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | ||
| protocol: EitherOutput::First(protocol), | ||
| info: Either::Left(info), | ||
| }) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | ||
| FullyNegotiatedInbound { protocol, info }, | ||
| ))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can combine them for select and either because those are fundamentally different.
swarm/src/handler/either.rs
Outdated
| ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | ||
| protocol: EitherOutput::First(protocol), | ||
| info: Either::Left(info), | ||
| }) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | ||
| FullyNegotiatedInbound { protocol, info }, | ||
| ))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, one of them is using EitherOutput which we need because Either doesn't implement AsyncRead + AsyncWrite.
See #2650.
| match fully_negotiated_outbound.transpose() { | ||
| Either::Left(f) => self | ||
| .proto1 | ||
| .on_connection_event(ConnectionEvent::FullyNegotiatedOutbound(f)), | ||
| Either::Right(f) => self | ||
| .proto2 | ||
| .on_connection_event(ConnectionEvent::FullyNegotiatedOutbound(f)), | ||
| } | ||
| } | ||
| ConnectionEvent::FullyNegotiatedInbound(fully_negotiated_inbound) => { | ||
| self.on_fully_negotiated_inbound(fully_negotiated_inbound) | ||
| match fully_negotiated_inbound.transpose() { | ||
| Either::Left(f) => self | ||
| .proto1 | ||
| .on_connection_event(ConnectionEvent::FullyNegotiatedInbound(f)), | ||
| Either::Right(f) => self | ||
| .proto2 | ||
| .on_connection_event(ConnectionEvent::FullyNegotiatedInbound(f)), | ||
| } | ||
| } | ||
| ConnectionEvent::AddressChange(address) => { | ||
| #[allow(deprecated)] | ||
| self.proto1.inject_address_change(address.new_address); | ||
| #[allow(deprecated)] | ||
| self.proto2.inject_address_change(address.new_address) | ||
| self.proto1 | ||
| .on_connection_event(ConnectionEvent::AddressChange(AddressChange { | ||
| new_address: address.new_address, | ||
| })); | ||
|
|
||
| self.proto2 | ||
| .on_connection_event(ConnectionEvent::AddressChange(AddressChange { | ||
| new_address: address.new_address, | ||
| })); | ||
| } | ||
| ConnectionEvent::DialUpgradeError(dial_upgrade_error) => { | ||
| self.on_dial_upgrade_error(dial_upgrade_error) | ||
| match dial_upgrade_error.transpose() { | ||
| Either::Left(err) => self | ||
| .proto1 | ||
| .on_connection_event(ConnectionEvent::DialUpgradeError(err)), | ||
| Either::Right(err) => self | ||
| .proto2 | ||
| .on_connection_event(ConnectionEvent::DialUpgradeError(err)), | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would be better to do it like this for the either::Handler as well? i.e. only transpose the inner type instead of the entire event and matching on the tuple.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah you are right Thomas, you had already mentioned before sorry it slipped me. It makes sense cause then we don't need Err for AddressChange. Updated ptal!
do it per variant instead of on the ConnectionEvent itself, so that we no longer need the Err on the case of AddressChange.
017641e to
a6c052d
Compare
thomaseizinger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Nice to see it being a negative diff!
Sorry I missed this on #3264
Description
Finishes work first started with #2832
Notes
review by commit is suggested :)
Links to any relevant issues
Open Questions
Change checklist