From a59e39a6a8336f5fddf51171da848262f7ff6a78 Mon Sep 17 00:00:00 2001 From: Ryo Onodera Date: Thu, 19 Dec 2024 00:20:46 +0900 Subject: [PATCH] Explain the odd transaction_status_sender.is_some() --- unified-scheduler-pool/src/lib.rs | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/unified-scheduler-pool/src/lib.rs b/unified-scheduler-pool/src/lib.rs index f44e0bb3fc6e8c..66f199814c39de 100644 --- a/unified-scheduler-pool/src/lib.rs +++ b/unified-scheduler-pool/src/lib.rs @@ -449,10 +449,17 @@ impl TaskHandler for DefaultTaskHandler { BlockVerification => vec![index], BlockProduction => { let mut vec = vec![]; + // transaction_status_sender is usually None for staked nodes because it's only + // used for RPC-related additional data recording. However, a staked node could + // also be running with rpc functionalities during development. So, we need to + // correctly support the use case for produced blocks as well, like verified blocks + // via the replaying stage. + // Refer `record_token_balances` in `execute_batch()` as this conditional treatment + // is mirrored from it. if handler_context.transaction_status_sender.is_some() { - // Create empty vec with the exact needed capacity, which will be filled inside - // `execute_batch()` below. Otherwise, excess cap would be reserved on - // `.push(transaction_index)` in it. + // Adjust the empty new vec with the exact needed capacity, which will be + // filled inside `execute_batch()` below. Otherwise, excess cap would be + // reserved on `.push(transaction_index)` in it. vec.reserve_exact(1); } vec