GH-598: fixes driven from debugging - review 2#743
GH-598: fixes driven from debugging - review 2#743bertllll wants to merge 3 commits intoGH-598-cosmetics-1-review-1from
Conversation
|
You have run out of free Bugbot PR reviews for this billing cycle. This will reset on November 14. To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial. |
| } | ||
|
|
||
| impl NewPostingsDebugContainer { | ||
| impl NewChargessDebugContainer { |
There was a problem hiding this comment.
We want single 's' in the Charges.
| MSG_ID_INCREMENTER.fetch_add(1, Ordering::Relaxed) | ||
| } | ||
| fn last_used_id(&self) -> u32 { | ||
| MSG_ID_INCREMENTER.load(Ordering::Relaxed) - 1 |
There was a problem hiding this comment.
Why is there -1 at the end? Correct me if I'm wrong but the last I'd should be the current value, not current value -1.
| let same_id_2 = subject.last_used_id(); | ||
| let new_id_2 = subject.new_id(); | ||
|
|
||
| assert_eq!(new_id, same_id_1); |
There was a problem hiding this comment.
I would suggest if you increment the value first and then return it in the new_id method. That way you won't need to use -1 in the load_id method.
utkarshg6
left a comment
There was a problem hiding this comment.
Continue at node/src/sub_lib/accountant.rs:136
| } | ||
|
|
||
| fn last_used_id(&self) -> u32 { | ||
| todo!() |
There was a problem hiding this comment.
You can write something here, I don't like it empty.
| payload_size, | ||
| service_rate: self.per_routing_service, | ||
| byte_rate: self.per_routing_byte, | ||
| service: ServiceProvided { |
There was a problem hiding this comment.
I dunno why you nested it like that, looks unnecessary, unless there's a sibling field.
| pub payload_size: usize, | ||
| pub service_rate: u64, | ||
| pub byte_rate: u64, | ||
| pub trait AccountableServiceWithTraceLog { |
There was a problem hiding this comment.
This would be additional complexity while searching for logs in the production code. I personally prefer a direct print of log using macros. Introducing a layer of abstraction here apparently can make it harder to search for logs.
| fn trace_log_msg(&self, msg_id: u32) -> String; | ||
| } | ||
|
|
||
| pub trait MessageWithServicesProvided { |
There was a problem hiding this comment.
Prefer enum based approach here
#[derive(Clone, PartialEq, Eq, Debug, Message)]
pub struct ReportServiceProvidedMessage {
pub service: ServiceProvided,
pub service_type: ServiceType,
}
#[derive(Clone, PartialEq, Eq, Debug)]
pub enum ServiceType {
Exit,
Routing,
}
impl ReportServiceProvidedMessage {
pub fn new_exit_service(service: ServiceProvided) -> Self {
Self {
service,
service_type: ServiceType::Exit,
}
}
pub fn new_routing_service(service: ServiceProvided) -> Self {
Self {
service,
service_type: ServiceType::Routing,
}
}
}
impl ReportServiceProvidedMessage {
fn services_provided(&self) -> &ServiceProvided {
&self.service
}
fn service_type(&self) -> ServiceType {
self.service_type
}
}| pub routing: RoutingServicesConsumed, | ||
| } | ||
|
|
||
| impl AccountableServiceWithTraceLog for ExitServiceConsumed { |
There was a problem hiding this comment.
Lines 219...234 could be replaced by a single log message which just prints the service type similar to other values in the trace log message.
| pub byte_rate: u64, | ||
| } | ||
|
|
||
| pub enum ServiceProvidedTraceLogWrapper<'a> { |
There was a problem hiding this comment.
Again it should be done other way around. You should use the enum ServiceType here. Refer to this comment - https://github.com/MASQ-Project/Node/pull/743/files#r2533460766
| let exit_service_msg = ReportExitServiceProvidedMessage { | ||
| service: service.clone(), | ||
| }; | ||
| let routing_service_msg = ReportRoutingServiceProvidedMessage { service }; |
There was a problem hiding this comment.
This test will change slightly. You should consider a test with 2 cases along with a helper function.
utkarshg6
left a comment
There was a problem hiding this comment.
Continue at node/src/accountant/logging_utils/accounting_msgs_debug.rs
| ) -> Option<LoggableStats> { | ||
| self.record_new_charges_by_msg_type(new_charges, msg_type); | ||
|
|
||
| self.maybe_dump_stats_by_msg_type(log_window_size, msg_type) |
There was a problem hiding this comment.
I'd safely remove the suffix _by_msg_type from the fn names.
| let mut new_charge_feeds_per_msg = | ||
| generate_new_charge_feeds_representing_msgs(log_window_size); | ||
| let expected_sorted_stats = | ||
| construct_expected_sorted_stats_from_generated_new_charges(&new_charge_feeds_per_msg); |
There was a problem hiding this comment.
The variable names are less clear and verbose. Kindly change it to something familiar like:
new_charge_feeds_per_msg -> test_msgs
expected_sorted_stats -> expected_stats
| let mut subject = AccountingMessageTracker::default(); | ||
| assert_empty_stats(&subject); | ||
| let charge_msg_matching_the_window_size = | ||
| new_charge_feeds_per_msg.remove(log_window_size as usize - 1 - 1); |
There was a problem hiding this comment.
These two -1 are less clear. It's hard to decipher what individual subtractions are trying to achieve. I'd suggest to break this into two steps and use different variable names. It will shed some light on why these subtractions happened.
| test_msgs_of_count_window_size_minus_one( | ||
| &mut subject, | ||
| msg_type, | ||
| log_window_size, |
There was a problem hiding this comment.
Also, the use of window size is unclear in this testing fn as whole. I'd like if we can make it clearer.
| assert_provided_loggable_stats(result, msg_type, log_window_size, expected_sorted_stats); | ||
| assert_empty_stats(&subject); | ||
|
|
||
| retest_after_emptied(&mut subject, msg_type); |
There was a problem hiding this comment.
Optional: There are so many fns being used, I'd converted it into a builder pattern and would implement these fns on the structure. If you're ready for more adventure then only embark on it, otherwise it's totally fine to leave it this way.
utkarshg6
left a comment
There was a problem hiding this comment.
Continue at node/src/accountant/mod.rs
| fn record_service_provided(&self, service: &ServiceProvided) -> Option<NewCharge> { | ||
| let byte_charge = service.byte_rate as u128 * (service.payload_size as u128); | ||
| let total_charge = service.service_rate as u128 + byte_charge; | ||
| let wallet = &service.paying_wallet; |
| } | ||
| fn handle_report_service_provided_message<AccountingMessage>(&mut self, msg: AccountingMessage) | ||
| where | ||
| AccountingMessage: MessageWithServicesProvided, |
There was a problem hiding this comment.
This should go away once you decide to use the structure instead of the trait implementation. The enum based approach will make things easier for you here. You can thank me later.
| msg.payload_size, | ||
| &msg.paying_wallet, | ||
| ); | ||
| trace_log_wrapper.log_trace(self.logging_kit(MsgIdRequested::New)); |
There was a problem hiding this comment.
This code is worrisome. I think if we had to find the log once we have the log file with us, then at that time, it'll be difficult for us to find this.
This layer of abstraction is the issue, if it wasn't for a use case like logging, I'd appreciate it and here, I'm concerned.
No description provided.