-
Notifications
You must be signed in to change notification settings - Fork 94
LogServer Bilrost (v2) message types #3176
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
85a78f1
to
2c0c399
Compare
crates/types/src/net/log_server.rs
Outdated
@@ -331,12 +417,29 @@ impl Released { | |||
} | |||
} | |||
|
|||
impl V2Convertible for Released { |
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.
NOTICE:
The Released
message (and other response messages) carries only a header
. This allows us to convert this message (and similar ones) directly to message::LogServerResponseHeader
over the wire so we don't have to create a shadow messages for this as well.
But this comes with a cavity. We can't modify this type later to add more fields to Released
without breaking compatibility. The only workaround in that case is to
flatten header
directly inside Release
. Then add the extra field.
To avoid this situation we can enforce the following conventions:
- Only use this pattern if you are 100% sure this message will not change in the future (Will
Released
ever has new fields). In that case create separate message type. - Create a
GenericResponse
type, that only has theheader
field. Then use it asTarget
in theV2Convertible
implementation for all messages that matches. Now if we need to add more fields toReleased
it then can get its own shadow type without breaking compatibility.
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've removed Released in my changes, it's not used and not needed.
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 is not about the Release message itself but rather how we serialize it (or similar messages over the wire)
9901d77
to
cccbad3
Compare
9893a58
to
40a4ad9
Compare
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 @mohammedazmy. I've left some notes for your consideration.
da3a2e9
to
88263f0
Compare
5cbb765
to
8015d48
Compare
628666e
to
512c087
Compare
30639fa
to
306fd90
Compare
@AhmedSoliman This PR has improved a lot (IMHO) after using the |
af79d28
to
0752b5a
Compare
TailUpdateQuery::Unknown => { | ||
unreachable!() | ||
} |
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.
Wouldn't it be better to fail the operation and return TailUpdated with_status(Status::Malformed)?
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.
Oh, definitely! Sorry I didn't see it.
crates/types/src/logs/mod.rs
Outdated
|
||
impl From<&super::KeyFilter> for KeyFilter { | ||
fn from(value: &crate::logs::KeyFilter) -> Self { | ||
use crate::logs::KeyFilter::*; |
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 wouldn't recommend this unless the number of variants is (a) too large and (b) doesn't include names that might conflict with std lib's prelude types. This case doesn't meet (a) and it's borderline close to hitting (b) due to rust's Any
type, albeit it's not in prelude.
NetSerde, | ||
)] | ||
#[bilrost_as(dto::Payloads)] | ||
pub struct Payloads(Arc<[Record]>); |
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.
Does this break compatibility with V1?
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 it doesn't. I already have tested it also to be sure against a V1 node. Serde serializes newtypes as it's inner type.
45fb08d
to
ca902b3
Compare
crates/types/src/net/log_server.rs
Outdated
@@ -181,7 +204,7 @@ define_logserver_rpc! { | |||
|
|||
// WaitForTail | |||
define_logserver_rpc! { | |||
@request = WaitForTail, | |||
@request = WaitForTail , |
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.
@request = WaitForTail , | |
@request = WaitForTail, |
Move log server messages to Bilrost v2 by either derive bilrost::Message or implement a DTO
LogServer Bilrost (v2) message types
Move log server messages to Bilrost v2 by either derive bilrost::Message
or implement a DTO
Stack created with Sapling. Best reviewed with ReviewStack.