8000 Extracted client API in near_network. by pompon0 · Pull Request #7839 · near/nearcore · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Extracted client API in near_network. #7839

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

Merged
merged 8 commits into from
Oct 18, 2022

Conversation

pompon0
Copy link
Contributor
@pompon0 pompon0 commented Oct 17, 2022

This way the client actors are abstracted out from the network crate.
Also moved the multiplexing PeerMessage -> (View)ClientActor API, from PeerActor to NetworkState.
Improved tests which started failing (this PR doesn't introduce semantic changes, therefore those tests were apparently too fragile).

@pompon0 pompon0 requested a review from matklad October 17, 2022 11:43
@pompon0 pompon0 requested a review from a team as a code owner October 17, 2022 11:43
Copy link
Contributor
@matklad matklad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, looks most excellent to me!

Didn't yet do review for correctness here

pub type Result<T> = std::result::Result<T, ReasonForBan>;

impl Client {
pub async fn tx_status_request(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, love this interface with a bunch of functions very much, kudos!

Merging Client & ViewClient behind a single interface is also a very good idea imo: VC should really be just an impl detail of Client.

Comment on lines 260 to 269
match self.view_client_addr.send(NetworkViewClientMessages::BlockRequest(hash)).await {
Ok(NetworkViewClientResponses::Block(block)) => Ok(Some(*block)),
Ok(NetworkViewClientResponses::NoResponse) => Ok(None),
Ok(NetworkViewClientResponses::Ban { ban_reason }) => Err(ban_reason),
Ok(resp) => panic!("unexpected ViewClientResponse: {resp:?}"),
Err(err) => {
tracing::error!("mailbox error: {err}");
Ok(None)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could extract some of the boilerplate here into a helper:

self.send_view(NetworkViewClientMessages::BlockRequest(hash), |res| match res {
            NetworkViewClientResponses::Block(block) => Some(*block),
            NetworkViewClientResponses::NoResponse => None,
            resp => panic!("unexpected ViewClientResponse: {resp:?}"),
})

(eg, have the MailBox error be unwrap_or_defaulted, and handling Ban automatically. Perhaps even merging mailbox closed & no_response).

I don't think we should though, just explicitly writing out matches is simpler.

Copy link
Contributor Author

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 should either. All of the content of this file is boilerplate, so let it be as straightforward as possible.

@@ -699,7 +658,7 @@ pub enum AccountOrPeerIdOrHash {
Hash(CryptoHash),
}

pub struct RawRoutedMessage {
pub(crate) struct RawRoutedMessage {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

let peer_id = conn.peer_info.id.clone();
ctx.spawn(
wrap_future(async move {
network_state.receive_message(&clock, peer_id, msg, was_requested).await
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks a bit strange that this is routed via the global network_state rather than local connection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want this PeerMessage handler to be agnostic to where the request came from (in particular the response should be sent outside of the handler). It is true that right now it is far from perfect, because even Client wants to get sometimes the peer_id of the sender for some reason. I'll move it back to PeerActor for now, and I'll think how to rearrange it later.

@matklad matklad self-requested a review October 17, 2022 13:27
Copy link
Contributor
@matklad matklad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this has higher than usual chance of breaking pytests, please keep an eye on that!

@near-bulldozer near-bulldozer bot merged commit 864cc29 into master Oct 18, 2022
@near-bulldozer near-bulldozer bot deleted the gprusak-client-for-network branch October 18, 2022 18:48
nikurt pushed a commit that referenced this pull request Oct 19, 2022
This way the client actors are abstracted out from the network crate.
Also moved the multiplexing PeerMessage -> (View)ClientActor API, from PeerActor to NetworkState.
Improved tests which started failing (this PR doesn't introduce semantic changes, therefore those tests were apparently too fragile).
@mina86
Copy link
Contributor
mina86 commented Oct 24, 2022

This breaks a whole bunch of tests, see #7916

@pompon0
Copy link
Contributor Author
pompon0 commented Oct 24, 2022

I know, I'm working on a fix + mechanism to prevent this kind of bugs in the future: #7895

nikurt pushed a commit that referenced this pull request Nov 9, 2022
This way the client actors are abstracted out from the network crate.
Also moved the multiplexing PeerMessage -> (View)ClientActor API, from PeerActor to NetworkState.
Improved tests which started failing (this PR doesn't introduce semantic changes, therefore those tests were apparently too fragile).
near-bulldozer bot pushed a commit that referenced this pull request Jan 18, 2023
I have incorrectly removed it in #7839 (by accident).
Also I've dropped producing message of this type in this PR, so that support for receiving StateResponse can be dropped in the future release.
marcelo-gonzalez pushed a commit to marcelo-gonzalez/nearcore that referenced this pull request Jan 26, 2023
I have incorrectly removed it in near#7839 (by accident).
Also I've dropped producing message of this type in this PR, so that support for receiving StateResponse can be dropped in the future release.
marcelo-gonzalez pushed a commit to marcelo-gonzalez/nearcore that referenced this pull request Jan 26, 2023
I have incorrectly removed it in near#7839 (by accident).
Also I've dropped producing message of this type in this PR, so that support for receiving StateResponse can be dropped in the future release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0