Skip to content
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

Sync active request byrange ids logs #6869

Open
wants to merge 4 commits into
base: sync-active-request-byrange
Choose a base branch
from

Conversation

dapplion
Copy link
Collaborator

Issue Addressed

Writing and running tests I noted that the sync RPC requests are very verbose now.

DataColumnsByRootRequestId { id: 123, requester: Custody(CustodyId { requester: CustodyRequester(SingleLookupReqId { req_id: 121, lookup_id: 101 }) }) }

Since this Id is logged rather often I believe there's value in

  1. Making them more succinct for log verbosity
  2. Make them a string that's easy to copy and work with elastic

Proposed Changes

Write custom Display implementations to render Ids in a more DX format

_ DataColumnsByRootRequestId with a block lookup_

123/Custody/121/Lookup/101

DataColumnsByRangeRequestId

123/122/RangeSync/0/5492900659401505034

Also made the logs format and text consistent across all methods

@dapplion dapplion requested a review from jxs as a code owner January 27, 2025 14:07
@dapplion dapplion requested a review from jimmygchen January 27, 2025 14:07
@dapplion dapplion added ready-for-review The code is ready for review syncing UX-and-logs labels Jan 27, 2025
Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

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

HI Lion, overall looks good to me, left some suggestions!

// Since each request Id is deeply nested with various types, if rendered with Debug on logs they
// take too much visual space. This custom Display implementations make the overall Id short while
// not losing information
impl Display for BlocksByRangeRequestId {
Copy link
Member

Choose a reason for hiding this comment

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

we can make it dry'er by defining a simple macro that impl's Display for the structs:

macro_rules! impl_display {
    ($structname: ty, $format: literal, $($field:ident),*) => {
        impl Display for $structname {
            fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result {
                write!(f, $format, $(self.$field,)*)
            }
        }
    };
}

and then calling it for the simple cases:

impl_display! {BlocksByRangeRequestId, "{}/{}", id, parent_request_id}
impl_display! {DataColumnsByRangeRequestId, "{}/{}", id, parent_request_id}
impl_display! {SingleLookupReqId, "{}/lookup/{}", req_id, lookup_id}

}
}

#[cfg(test)]
Copy link
Member

Choose a reason for hiding this comment

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

nit:
I don't think we need tests for this, Display is reflected on the logs, if it's not according to what expected it's clear where one change, was there a special reason you added tests for?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Mainly are regression tests, to ensure that a future mantainer understands the intended format and doesn't change it unintentionally

let processor = self.clone();
let id = process_id.clone();
Copy link
Member

Choose a reason for hiding this comment

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

nit: we can avoid cloning here, we can make ChainSegmentProcessId derive Copy

resp: Option<RpcResponseResult<R>>,
peer_id: PeerId,
get_count: F,
Copy link
Member

Choose a reason for hiding this comment

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

why not just accept the count as an usize?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Because I want to render the count of items in the Ok response

@dapplion dapplion force-pushed the sync-active-request-byrange branch from b0774e0 to 8e0758c Compare January 29, 2025 09:29
@jimmygchen jimmygchen added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Jan 30, 2025
@jimmygchen
Copy link
Member

Tests are failing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
syncing UX-and-logs waiting-on-author The reviewer has suggested changes and awaits thier implementation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants