Skip to content

Conversation

muhamadazmy
Copy link
Contributor

@muhamadazmy muhamadazmy commented Apr 17, 2025

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.

@@ -331,12 +417,29 @@ impl Released {
}
}

impl V2Convertible for Released {
Copy link
Contributor Author

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 the header field. Then use it as Target in the V2Convertible implementation for all messages that matches. Now if we need to add more fields to Released it then can get its own shadow type without breaking compatibility.

Copy link
Contributor

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.

Copy link
Contributor Author

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)

@muhamadazmy muhamadazmy force-pushed the pr3176 branch 2 times, most recently from 9901d77 to cccbad3 Compare April 23, 2025 11:14
@muhamadazmy muhamadazmy force-pushed the pr3176 branch 4 times, most recently from 9893a58 to 40a4ad9 Compare April 25, 2025 10:38
@muhamadazmy muhamadazmy changed the title WIP: LogServer v2 message types LogServer Bilrost (v2) message types Apr 25, 2025
@muhamadazmy muhamadazmy marked this pull request as ready for review April 25, 2025 10:38
Copy link
Contributor

@AhmedSoliman AhmedSoliman left a 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.

@muhamadazmy muhamadazmy force-pushed the pr3176 branch 11 times, most recently from da3a2e9 to 88263f0 Compare April 28, 2025 09:47
@muhamadazmy muhamadazmy force-pushed the pr3176 branch 3 times, most recently from 5cbb765 to 8015d48 Compare April 29, 2025 07:10
@muhamadazmy muhamadazmy force-pushed the pr3176 branch 2 times, most recently from 628666e to 512c087 Compare April 30, 2025 11:07
@muhamadazmy muhamadazmy force-pushed the pr3176 branch 4 times, most recently from 30639fa to 306fd90 Compare April 30, 2025 11:32
@muhamadazmy
Copy link
Contributor Author

@AhmedSoliman This PR has improved a lot (IMHO) after using the BilrostAs macro. It minimized the number of structs that needed a dto. I would love to get your feedback specially around the design decision that I am not 100% sure about, like introducing some unknown variants only for the type default state required by Bilrost empty state and how to handle them.

Comment on lines 425 to 428
TailUpdateQuery::Unknown => {
unreachable!()
}
Copy link
Contributor

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)?

Copy link
Contributor Author

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.


impl From<&super::KeyFilter> for KeyFilter {
fn from(value: &crate::logs::KeyFilter) -> Self {
use crate::logs::KeyFilter::*;
Copy link
Contributor

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]>);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@@ -181,7 +204,7 @@ define_logserver_rpc! {

// WaitForTail
define_logserver_rpc! {
@request = WaitForTail,
@request = WaitForTail ,
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
@request = WaitForTail ,
@request = WaitForTail,

Move log server messages to Bilrost v2 by either derive bilrost::Message
or implement a DTO
@muhamadazmy muhamadazmy merged commit fa6aa2f into restatedev:main May 6, 2025
58 of 60 checks passed
@muhamadazmy muhamadazmy deleted the pr3176 branch May 6, 2025 12:06
@github-actions github-actions bot locked and limited conversation to collaborators May 6, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants