Add versioning to request response protocols #2362

acerone85 · 2024-10-15T20:34:57Z

Linked Issues/PRs

Related issue: #1311

Context

The P2P service uses the request_response protocol to let peer request information (e.g. block headers, or transactions in the tx pool) from other peers.
Currently, the P2P service provides a protocol /fuel/req_res/0.0.1, which defines responses to have
an Option value. When a request from a peer is unsuccessful, we send a None value as a response, wrapped around the relevant response type.

In practice, we want to be able to send more meaningful information in responses when requests are unsuccessful, in the form of error codes. This requires implementing a new version of the protocol /fuel/req_res/0.0.2 where Response messages are changed to contain error codes.
Because we want to be backward compatible with peers that will only use the version 0.0.1 of the protocol, we must account for requests sent by, and responses sent to, those peers.

Description

Rename the ResponseMessage type in the P2P service to LegacyResponseMessage
Add a ResponseMessageErrorCode enum, which for now only contains a LegacyNodeEmptyResponse enum.
Implement a new ResponseMessage type that returns a Result<_, ResponseMessageErrorCode> wrapped around enum variants
Change P2P service to use the neq ResponseMessage type. Responses previously returned as None are now returned as Err<LegacyNodeEmptyResponse>.
Change the PostcardCodec to serialize and deserialize according to two different versions of the /fuel/req_res protocol: /fuel/req_res/0.0.1 and /fuel/req_res/0.0.2.
Serialization and deserialization of responses using /fuel/req_res/0.0.1 are performed by first converting a ResponseMessage into a LegacyResponseMessage and vicecersa, thus preserving backward-compatibility
Change the req_res behaviour used by the P2P service to use both version of the req_res protocol.

TODO (here or in different PRs)

Investigate how protocols are exchanged during peer handshakes. We don't want two nodes that both understand /fuel/req_res/0.0.2 to communicate using /fuel/req_res/0.0.1.
Add more meaningful error codes.

Checklist

Breaking changes are clearly marked as such in the PR description and changelog
New behavior is reflected in tests
The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

I have reviewed the code myself
I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

Rust SDK
Sway compiler
Platform documentation (for out-of-organization contributors, the person merging the PR will do this)
Someone else?

…_service

…l in the PeerManager table

…the request response protocol to use

…-requests

This reverts commit f3b7db3b0f4aa92f2606c87ed6f65f4798734889.

…ses to unsuccessful requests

AurelienFT · 2024-10-20T15:02:33Z

crates/services/p2p/src/request_response/messages.rs

@@ -32,14 +34,77 @@ pub enum RequestMessage {
    TxPoolFullTransactions(Vec<TxId>),
 }

+// TODO: Do we want explicit status codes or an Error type?


I think it's not a big problem to have more detailed error (with specific block id or thing like that) as soon as we add a limit on the size of the error.

MitchTurner

WIP. I'm gonna give this another pass soon.

MitchTurner · 2024-10-22T09:27:44Z

crates/services/p2p/src/request_response/messages.rs

 #[derive(Debug, Clone, Serialize, Deserialize)]
-pub enum ResponseMessage {
+pub enum LegacyResponseMessage {


I'm trying to decide if it would make more sense to name this V1ResponseMessage? The term Legacy will become ambiguous once we add a third protocol."

Same question applies to ResponseMessage.

Or you could name it something descriptive like the protocol consts, e.g. REQUEST_RESPONSE_WITH_ERROR_CODES_PROTOCOL_ID

MitchTurner · 2024-10-22T09:36:06Z

crates/services/p2p/src/codecs/postcard.rs

@@ -160,30 +176,200 @@ impl GossipsubCodec for PostcardCodec {
    }
 }

+// TODO: Remove this NetworkCodec


Have you created an issue? And I think the TODO should be on the trait itself, rather than one of the impls.

Yes, issue moved to the trait definition and referenced in b710d8d

MitchTurner · 2024-10-22T09:57:47Z

crates/services/p2p/src/codecs/postcard.rs

+    #[tokio::test]
+    async fn serialzation_roundtrip_using_v2() {
+        let sealed_block_headers = vec![SealedBlockHeader::default()];
+        let response = ResponseMessage::SealedHeaders(Ok(sealed_block_headers.clone()));
+        let mut codec = PostcardCodec::new(1024);
+        let mut buf = Vec::with_capacity(1024);
+        codec
+            .write_response(&PostcardProtocol::V2, &mut buf, response)
+            .await
+            .expect("Valid Vec<SealedBlockHeader> should be serialized using v1");
+
+        let deserialized = codec
+            .read_response(&PostcardProtocol::V2, &mut buf.as_slice())
+            .await
+            .expect("Valid Vec<SealedBlockHeader> should be deserialized using v1");
+
+        match deserialized {
+            ResponseMessage::SealedHeaders(Ok(sealed_block_headers_response)) => {
+                assert_eq!(sealed_block_headers, sealed_block_headers_response);
+            }
+            other => {
+                panic!("Deserialized to {other:?}, expected {sealed_block_headers:?}")
+            }
+        }
+    }


Nit: I prefer all UTs include given/when/then blocks and start the name with the SUT.

Suggested change

#[tokio::test]

async fn serialzation_roundtrip_using_v2() {

let sealed_block_headers = vec![SealedBlockHeader::default()];

let response = ResponseMessage::SealedHeaders(Ok(sealed_block_headers.clone()));

let mut codec = PostcardCodec::new(1024);

let mut buf = Vec::with_capacity(1024);

codec

.write_response(&PostcardProtocol::V2, &mut buf, response)

.await

.expect("Valid Vec<SealedBlockHeader> should be serialized using v1");

let deserialized = codec

.read_response(&PostcardProtocol::V2, &mut buf.as_slice())

.await

.expect("Valid Vec<SealedBlockHeader> should be deserialized using v1");

match deserialized {

ResponseMessage::SealedHeaders(Ok(sealed_block_headers_response)) => {

assert_eq!(sealed_block_headers, sealed_block_headers_response);

}

other => {

panic!("Deserialized to {other:?}, expected {sealed_block_headers:?}")

}

}

}

#[tokio::test]

async fn codec__v1_serialzation_roundtrip() {

/// given

let sealed_block_headers = vec![SealedBlockHeader::default()];

let response = ResponseMessage::SealedHeaders(Ok(sealed_block_headers.clone()));

let mut codec = PostcardCodec::new(1024);

let mut buf = Vec::with_capacity(1024);

/// when

codec

.write_response(&PostcardProtocol::V2, &mut buf, response)

.await

.expect("Valid Vec<SealedBlockHeader> should be serialized using v1");

let deserialized = codec

.read_response(&PostcardProtocol::V2, &mut buf.as_slice())

.await

.expect("Valid Vec<SealedBlockHeader> should be deserialized using v1");

/// then

match deserialized {

ResponseMessage::SealedHeaders(Ok(sealed_block_headers_response)) => {

assert_eq!(sealed_block_headers, sealed_block_headers_response);

}

other => {

panic!("Deserialized to {other:?}, expected {sealed_block_headers:?}")

}

}

}

This is a round-trip test, which I consider an exception to the rule that each test should be testing one thing (it's just so succinct)

Given/When/Then sections added in cec899c

MitchTurner · 2024-10-22T10:02:04Z

crates/services/p2p/src/codecs/postcard.rs

+            // We cannot access the codec trait from an old node here, 
+            // so we deserialize directly using the `LegacyResponseMessage` type.
+            deserialize::<LegacyResponseMessage>(&buf).expect("Deserialization as LegacyResponseMessage should succeed");
+        match deserialized_as_legacy {


I'd prefer a matches! macro here (and probably on all the tests) because when I'm reading a test I'm always looking for an explicit expected condition, not an implicit one like here.

nice :) I have refactored the tests to use matches! in 4280781

MitchTurner · 2024-10-22T10:06:49Z

crates/services/p2p/src/codecs/postcard.rs

+    #[tokio::test]
+    async fn backward_compatibility_v1_read_error_response() {
+        let response = ResponseMessage::SealedHeaders(Err(
+            ResponseMessageErrorCode::ProtocolV1EmptyResponse,
+        ));
+        let mut codec = PostcardCodec::new(1024);
+        let mut buf = Vec::with_capacity(1024);
+        codec
+            .write_response(&PostcardProtocol::V1, &mut buf, response.clone())
+            .await
+            .expect("Valid Vec<SealedBlockHeader> is serialized using v1");
+
+        let deserialized_as_legacy =
+            // We cannot access the codec trait from an old node here, 
+            // so we deserialize directly using the `LegacyResponseMessage` type.
+            deserialize::<LegacyResponseMessage>(&buf).expect("Deserialization as LegacyResponseMessage should succeed");
+        match deserialized_as_legacy {
+            LegacyResponseMessage::SealedHeaders(None) => {}
+            other => {
+                panic!("Deserialized to {other:?}, expected {response:?}")
+            }
+        }
+    }


Another example of how to structure the tests:

Suggested change

#[tokio::test]

async fn backward_compatibility_v1_read_error_response() {

let response = ResponseMessage::SealedHeaders(Err(

ResponseMessageErrorCode::ProtocolV1EmptyResponse,

));

let mut codec = PostcardCodec::new(1024);

let mut buf = Vec::with_capacity(1024);

codec

.write_response(&PostcardProtocol::V1, &mut buf, response.clone())

.await

.expect("Valid Vec<SealedBlockHeader> is serialized using v1");

let deserialized_as_legacy =

// We cannot access the codec trait from an old node here,

// so we deserialize directly using the `LegacyResponseMessage` type.

deserialize::<LegacyResponseMessage>(&buf).expect("Deserialization as LegacyResponseMessage should succeed");

match deserialized_as_legacy {

LegacyResponseMessage::SealedHeaders(None) => {}

other => {

panic!("Deserialized to {other:?}, expected {response:?}")

}

}

}

#[tokio::test]

async fn codec__write_response_is_backwards_compatible_with_v1() {

// given

let response = ResponseMessage::SealedHeaders(Err(

ResponseMessageErrorCode::ProtocolV1EmptyResponse,

));

let mut codec = PostcardCodec::new(1024);

let mut buf = Vec::with_capacity(1024);

// when

codec

.write_response(&PostcardProtocol::V1, &mut buf, response.clone())

.await

.expect("Valid Vec<SealedBlockHeader> is serialized using v1");

let deserialized_as_legacy =

// We cannot access the codec trait from an old node here,

// so we deserialize directly using the `LegacyResponseMessage` type.

deserialize::<LegacyResponseMessage>(&buf).expect("Deserialization as LegacyResponseMessage should succeed");

// then

match deserialized_as_legacy {

LegacyResponseMessage::SealedHeaders(None) => {}

other => {

panic!("Deserialized to {other:?}, expected {response:?}")

}

}

}

I have changed the names of the tests to follow your suggestions in 6276af5

…-requests

xgreenx · 2024-10-22T17:50:09Z

crates/services/p2p/src/codecs/postcard.rs

+pub enum PostcardProtocol {
+    #[default]
+    V1,
+    V2,
+}


Why V1 is default if we prefer V2?

Thanks, this is a leftover for when I was doing protocol selection manually. In fact, we don't even need a Default version.
I have removed it in the follow-up MR: #2377 (commit ea4842c)

xgreenx · 2024-10-22T17:52:06Z

crates/services/p2p/src/p2p_service.rs

-                            ResponseMessage::Transactions(v) => {
-                                c.send((peer, Ok(v))).is_ok()
+                            V2ResponseMessage::Transactions(v) => {
+                                c.send((peer, Ok(v.ok()))).is_ok()


It would be nice to have the same TODO here

xgreenx · 2024-10-22T17:52:10Z

crates/services/p2p/src/p2p_service.rs

-                            ResponseMessage::TxPoolAllTransactionsIds(v) => {
-                                c.send((peer, Ok(v))).is_ok()
+                            V2ResponseMessage::TxPoolAllTransactionsIds(v) => {
+                                c.send((peer, Ok(v.ok()))).is_ok()


It would be nice to have the same TODO here

xgreenx · 2024-10-22T17:52:14Z

crates/services/p2p/src/p2p_service.rs

-                            ResponseMessage::TxPoolFullTransactions(v) => {
-                                c.send((peer, Ok(v))).is_ok()
+                            V2ResponseMessage::TxPoolFullTransactions(v) => {
+                                c.send((peer, Ok(v.ok()))).is_ok()


It would be nice to have the same TODO here

These are addressed in the follow-up MR (#2377), but I agree that in the future I should duplicate the TODO comment in all relevant places

## Linked Issues/PRs  Closes #1311 ## Description  This PR follows #2362, which introduces a new version of the protocol `/fuel/req_response/0.0.2` which allows to return Errors in the response. This PR makes the following changes: - [X] the different errors that can be returned in a response are implemented. - [X] The type of `ResponseSender` used by a peer to propagate received responses upstream is changed to allow the rrors to be propagated - [X] Error Responses received by a peer following a request are displayed with as log messages with `warning` level. ## Checklist - [ ] Breaking changes are clearly marked as such in the PR description and changelog - [ ] New behavior is reflected in tests - [ ] [The specification](https://github.com/FuelLabs/fuel-specs/) matches the implemented behavior (link update PR if changes are needed) ### Before requesting review - [ ] I have reviewed the code myself - [ ] I have created follow-up issues caused by this PR and linked them here ### After merging, notify other teams [Add or remove entries as needed] - [ ] [Rust SDK](https://github.com/FuelLabs/fuels-rs/) - [ ] [Sway compiler](https://github.com/FuelLabs/sway/) - [ ] [Platform documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+) (for out-of-organization contributors, the person merging the PR will do this) - [ ] Someone else?

acerone85 added 2 commits October 15, 2024 21:05

Add a module for versioning the request response protocols in the p2p…

ab26a0b

…_service

Record the latest compatible version for the request response protoco…

c9ba074

…l in the PeerManager table

acerone85 requested review from xgreenx, Dentosal and MitchTurner as code owners October 15, 2024 20:34

acerone85 linked an issue Oct 15, 2024 that may be closed by this pull request

Return better error messages from P2P requests #1311

Closed

P2PService uses peer manager information to determine the version of …

b3d3219

…the request response protocol to use

acerone85 changed the base branch from release/v0.40.0 to master October 15, 2024 22:28

acerone85 added 6 commits October 16, 2024 07:29

Remove argument from Protocol::V1 and minor improvements to tests

8817d88

Merge branch 'master' into 1311-return-better-error-messages-from-p2p…

2ad29e4

…-requests

Merge branch 'master' into 1311-return-better-error-messages-from-p2p…

aedda11

…-requests

Add changelog entry

1855350

Fix compilation error

1fa98a4

Placate Clippy

6cebf0e

acerone85 changed the title ~~WIP - Add versioning to request response protocols~~ Add versioning to request response protocols Oct 16, 2024

acerone85 added 3 commits October 16, 2024 11:28

Version PostcardCodec

939939d

Revert "Revert changes"

e8c563c

This reverts commit f3b7db3b0f4aa92f2606c87ed6f65f4798734889.

P2P Service: Add /fuel/req_res/0.0.2 that sends error codes in respon…

f50a4d3

…ses to unsuccessful requests

acerone85 self-assigned this Oct 18, 2024

AurelienFT previously approved these changes Oct 20, 2024

View reviewed changes

acerone85 added 2 commits October 21, 2024 11:10

Prefer V2 over V1 when peers support both versions of the protocol

77841f0

Changelog

7160034

acerone85 dismissed AurelienFT’s stale review via 7160034 October 21, 2024 10:20

PostcardProtocol default implementation is now derived

b2b5b3c

acerone85 mentioned this pull request Oct 21, 2024

Integration test for nodes running on different versions of /fuel/req_res protocol #2374

Open

3 tasks

acerone85 added 2 commits October 21, 2024 19:25

Add tests to check serialization and deserialization of responses

93b4d06

Formatting

06e4177

MitchTurner reviewed Oct 22, 2024

View reviewed changes

acerone85 added 2 commits October 22, 2024 11:30

Merge branch 'master' into 1311-return-better-error-messages-from-p2p…

0729a87

…-requests

Remove TODO comment around ResponseMessageErrorCode definition

273bb34

acerone85 added 9 commits October 22, 2024 11:43

Rename LegacyResponseMessage into V1ResponseMessage

0865da6

Rename ResponseMessage into V2ResponseMessage

52290e7

Rename Request/Response protocol version constant variables

50f92ae

Refine TODO to remove NetworkCodec trait and reference github issue

b710d8d

Refine todos for error codes and add github issue when missing

8534f84

Add Given, When, Then sections to tests

cec899c

Remove trailing space in TODO comment

319ec8a

Use matches! macro in tests

4280781

Give more meaningful names to tests

6276af5

acerone85 requested a review from MitchTurner October 22, 2024 11:24

MitchTurner approved these changes Oct 22, 2024

View reviewed changes

AurelienFT approved these changes Oct 22, 2024

View reviewed changes

acerone85 merged commit bb6a42c into master Oct 22, 2024
39 checks passed

acerone85 deleted the 1311-return-better-error-messages-from-p2p-requests branch October 22, 2024 12:46

acerone85 mentioned this pull request Oct 22, 2024

Fuel/Request_Response v0.0.2: More meaningful error messages #2377

Merged

12 tasks

xgreenx reviewed Oct 22, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add versioning to request response protocols #2362

Add versioning to request response protocols #2362

acerone85 commented Oct 15, 2024 •

edited

Loading

AurelienFT Oct 20, 2024

MitchTurner left a comment

MitchTurner Oct 22, 2024

MitchTurner Oct 22, 2024

acerone85 Oct 22, 2024

MitchTurner Oct 22, 2024

acerone85 Oct 22, 2024

MitchTurner Oct 22, 2024

acerone85 Oct 22, 2024

MitchTurner Oct 22, 2024

acerone85 Oct 22, 2024

xgreenx Oct 22, 2024

acerone85 Oct 23, 2024

xgreenx Oct 22, 2024

xgreenx Oct 22, 2024

xgreenx Oct 22, 2024

acerone85 Oct 23, 2024

Add versioning to request response protocols #2362

Add versioning to request response protocols #2362

Conversation

acerone85 commented Oct 15, 2024 • edited Loading

Linked Issues/PRs

Context

Description

TODO (here or in different PRs)

Checklist

Before requesting review

After merging, notify other teams

Choose a reason for hiding this comment

MitchTurner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acerone85 commented Oct 15, 2024 •

edited

Loading