feat(request-response): Add support for custom dial options when making request to disconnected peer #5692
+249
−62
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We discussed #5634 at one of the community calls and the ways to approach it, one of the challenges we discussed was around the argument type and how to handle the case where
PeerId
is not specified inDialOpts
.I went with a relatively straightforward route: use
PeerId
when it is specified (same behavior as before this PR) and useConnectionId
otherwise, wrapping both into an enum to use as a key in internalHashMap
.Implementation ended up being fairly simple with the only breaking change being
peer
field inrequest_response::Event::OutboundFailure
changing fromPeerId
toOption<PeerId>
.Resolves #5634
Notes & open questions
One thing I do not like too much and only did for backwards compatibility purposes is additional
impl From<&PeerId> for DialOpts
such that existing calls continue to work. If changing&peer_id
topeer_id
is an acceptable breaking change then that impl can be removed.Change checklist