feat: adding additional fine grained spans#142
Merged
Conversation
…te_evnode, and try_new
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdd a crate-local drop-based duration recorder and instrument multiple node components with tracing spans that record timing and metadata (duration_ms, tx counts, payload_id, block/parent hashes); update logging and unit tests to assert span fields. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Claude finished @chatton's task —— View job Code Review for PR #142: Fine-Grained Tracing SpansI've conducted a comprehensive review of the tracing instrumentation changes. Here are my findings: Todo List:
Overall Assessment: ✅ APPROVE WITH RECOMMENDATIONSThis PR successfully adds comprehensive tracing instrumentation across the ev-reth codebase with good architectural design and test coverage. The implementation follows best practices for observability. 🎯 Strengths1. Excellent Tracing Utility Design
2. Comprehensive Coverage
3. Strong Test Coverage
4. Performance Conscious
|
chatton
changed the title
8 tasks
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
crates/node/src/payload_service.rs (1)
396-476: Consider extracting shared test setup into a helper.The genesis/provider/config/builder setup (lines 401–446) is nearly identical to the
try_build_span_has_expected_fieldstest above (lines 312–357), and also mirrors setup inbuilder.rsandvalidator.rstests. This boilerplate is copy-pasted across at least 6 test functions in this PR.A shared test helper (e.g., in
test_utils.rs) returning(EvolveEnginePayloadBuilder<MockEthProvider>, Header, B256)would reduce duplication and make future test additions easier.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/node/src/payload_service.rs` around lines 396 - 476, Extract the repeated genesis/provider/config/builder setup into a shared test helper (e.g., in a new test_utils.rs) that returns the needed items like (EvolveEnginePayloadBuilder<MockEthProvider>, Header, B256, ChainSpec or config) and update tests such as build_empty_payload_span_has_expected_fields and try_build_span_has_expected_fields to call that helper instead of duplicating lines ~401–446; locate the setup by looking for MockEthProvider, EvolveEnginePayloadBuilder, RpcPayloadAttributes, SealedHeader and PayloadConfig usage, move the creation of genesis_hash/genesis_header/provider/config/evm_config/evolve_builder into the helper, and have tests use the returned tuple to construct their specific Attrs or PayloadConfig before calling build_empty_payload or other builder methods.crates/node/src/builder.rs (1)
65-76:duration_mswon't be recorded on error paths.If
build_payloadreturns early via any of the?operators (lines 78–184),duration_msstaysEmptyon the span. This means error cases won't have timing data, which can be useful for diagnosing slow failures. Consider recordingduration_msunconditionally, e.g., with a drop guard or by restructuring to always record before returning.This pattern is repeated across all files in this PR, so noting it here as the primary location.
Example: use a scope guard to always record duration
One approach is a small helper or a
defer-style pattern:pub async fn build_payload( &self, attributes: EvolvePayloadAttributes, ) -> Result<SealedBlock<ev_primitives::Block>, PayloadBuilderError> { let _start = std::time::Instant::now(); + // Record duration on all exit paths (success and error). + let _record_duration = scopeguard::guard((), |_| { + Span::current().record("duration_ms", _start.elapsed().as_millis() as u64); + });Alternatively, the inner/outer pattern already used in
validate_evnode/validate_evnode_innerintxpool.rswould work here too.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/node/src/builder.rs` around lines 65 - 76, The span field duration_ms (declared in the #[instrument(...)] on build_payload) is left Empty on early-return/error paths because duration is only computed at function end; add an unconditional recorder (e.g., a small Drop guard created right after let _start = Instant::now() or restructure into inner/outer functions) that computes Instant::elapsed() and calls tracing::Span::current().record("duration_ms", &elapsed.as_millis()) so duration_ms is always set even when build_payload (or any early-return using ?) exits early; apply the same pattern wherever this #[instrument(..., duration_ms = tracing::field::Empty, ...)] pattern is used.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@crates/node/src/builder.rs`:
- Around line 65-76: The span field duration_ms (declared in the
#[instrument(...)] on build_payload) is left Empty on early-return/error paths
because duration is only computed at function end; add an unconditional recorder
(e.g., a small Drop guard created right after let _start = Instant::now() or
restructure into inner/outer functions) that computes Instant::elapsed() and
calls tracing::Span::current().record("duration_ms", &elapsed.as_millis()) so
duration_ms is always set even when build_payload (or any early-return using ?)
exits early; apply the same pattern wherever this #[instrument(..., duration_ms
= tracing::field::Empty, ...)] pattern is used.
In `@crates/node/src/payload_service.rs`:
- Around line 396-476: Extract the repeated genesis/provider/config/builder
setup into a shared test helper (e.g., in a new test_utils.rs) that returns the
needed items like (EvolveEnginePayloadBuilder<MockEthProvider>, Header, B256,
ChainSpec or config) and update tests such as
build_empty_payload_span_has_expected_fields and
try_build_span_has_expected_fields to call that helper instead of duplicating
lines ~401–446; locate the setup by looking for MockEthProvider,
EvolveEnginePayloadBuilder, RpcPayloadAttributes, SealedHeader and PayloadConfig
usage, move the creation of
genesis_hash/genesis_header/provider/config/evm_config/evolve_builder into the
helper, and have tests use the returned tuple to construct their specific Attrs
or PayloadConfig before calling build_empty_payload or other builder methods.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
crates/node/src/attributes.rscrates/node/src/builder.rscrates/node/src/payload_service.rscrates/node/src/txpool.rscrates/node/src/validator.rs
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@crates/node/src/attributes.rs`:
- Around line 215-227: The test currently only checks
span.has_field("duration_ms") which only verifies presence, not that the drop
guard populated a value; update the assertion to fetch the "duration_ms" field
from span (e.g., via span.field("duration_ms") or the test helper used to read
fields) and assert the returned value is Some and contains a numeric duration
(for example not null and > 0 or at least >= 0) so the test guarantees the
duration was actually recorded by the drop guard.
In `@crates/node/src/payload_service.rs`:
- Around line 23-24: The file crates/node/src/payload_service.rs is failing
formatting; run rustfmt by executing `cargo fmt --all` (or `rustfmt` on that
file) to normalize spacing, import ordering and line breaks — specifically
reformat the use statements such as `use
crate::tracing_ext::RecordDurationOnDrop;` and `use tracing::{info,
instrument};` and any surrounding function/struct definitions so the file passes
cargo fmt formatting checks.
In `@crates/node/src/txpool.rs`:
- Around line 414-418: The file fails rustfmt formatting; run rustfmt/cargo fmt
to reformat the affected code block containing the #[instrument(...)] attribute
(the attribute applied to the txpool method with fields
tx_hash/is_evnode/duration_ms) and re-run cargo fmt --all --check, then commit
the formatted changes so the formatting diff in crates/node/src/txpool.rs is
resolved.
In `@crates/node/src/validator.rs`:
- Around line 23-25: The file fails rustfmt; run the Rust formatter and commit
the formatted changes for crates/node/src/validator.rs (e.g., run cargo fmt
--all or rustfmt on that file) so imports like
crate::tracing_ext::RecordDurationOnDrop and tracing::{debug, info, instrument,
Span} and the rest of validator.rs conform to the project's formatting rules and
the CI formatting check passes.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
crates/node/src/attributes.rscrates/node/src/builder.rscrates/node/src/lib.rscrates/node/src/payload_service.rscrates/node/src/tracing_ext.rscrates/node/src/txpool.rscrates/node/src/validator.rs
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
crates/node/src/payload_service.rs (1)
394-474: Consider extracting shared test setup into a helper function.The test correctly validates the span fields for
build_empty_payload. However, lines 399-444 duplicate nearly identical setup code fromtry_build_span_has_expected_fields(lines 310-355). Extracting this into a helper would improve maintainability.♻️ Suggested helper extraction
// Add a helper at the top of the tests module: fn create_test_engine_builder() -> ( SpanCollector, tracing::subscriber::DefaultGuard, EvolveEnginePayloadBuilder<MockEthProvider>, B256, Header, ) { let collector = SpanCollector::new(); let guard = collector.as_default(); let genesis: alloy_genesis::Genesis = serde_json::from_str(include_str!("../../tests/assets/genesis.json")) .expect("valid genesis"); let chain_spec = Arc::new( ChainSpecBuilder::default() .chain(reth_chainspec::Chain::from_id(1234)) .genesis(genesis) .cancun_activated() .build(), ); let provider = MockEthProvider::default(); let genesis_hash = B256::from_slice( &hex::decode("2b8bbb1ea1e04f9c9809b4b278a8687806edc061a356c7dbc491930d8e922503") .unwrap(), ); let genesis_state_root = B256::from_slice( &hex::decode("05e9954443da80d86f2104e56ffdfd98fe21988730684360104865b3dc8191b4") .unwrap(), ); let genesis_header = Header { state_root: genesis_state_root, number: 0, gas_limit: 30_000_000, timestamp: 1710338135, base_fee_per_gas: Some(0), excess_blob_gas: Some(0), blob_gas_used: Some(0), parent_beacon_block_root: Some(B256::ZERO), ..Default::default() }; provider.add_header(genesis_hash, genesis_header.clone()); let config = EvolvePayloadBuilderConfig::from_chain_spec(chain_spec.as_ref()).unwrap(); let evm_config = EvolveEvmConfig::new(chain_spec); let evolve_builder = Arc::new(EvolvePayloadBuilder::new( Arc::new(provider), evm_config, config.clone(), )); let engine_builder = EvolveEnginePayloadBuilder { evolve_builder, config, }; (collector, guard, engine_builder, genesis_hash, genesis_header) }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/node/src/payload_service.rs` around lines 394 - 474, Extract the duplicated test setup into a helper (e.g. create_test_engine_builder) and use it from both build_empty_payload_span_has_expected_fields and try_build_span_has_expected_fields: move the SpanCollector creation, genesis deserialization, ChainSpecBuilder, MockEthProvider setup (including provider.add_header), genesis_header/hash, EvolvePayloadBuilderConfig/EvolveEvmConfig/EvolvePayloadBuilder instantiation and EvolveEnginePayloadBuilder construction into the helper and return the needed values (SpanCollector and its guard, EvolveEnginePayloadBuilder, genesis_hash, genesis_header); then replace the duplicated block in both tests with a call to create_test_engine_builder and use the returned symbols when building payloads and assertions (match names like SpanCollector, EvolveEnginePayloadBuilder, genesis_hash, genesis_header, payload_config).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@crates/node/src/builder.rs`:
- Around line 1-2: The import grouping is misformatted: move the standalone `use
crate::tracing_ext::RecordDurationOnDrop;` into the same `crate::` import group
as `EvolvePayloadBuilderConfig` and `EvEvmConfig` (or otherwise group all
`crate::...` uses together) so the file's imports conform to rustfmt
expectations; alternatively run `cargo fmt --all` to auto-fix.
---
Nitpick comments:
In `@crates/node/src/payload_service.rs`:
- Around line 394-474: Extract the duplicated test setup into a helper (e.g.
create_test_engine_builder) and use it from both
build_empty_payload_span_has_expected_fields and
try_build_span_has_expected_fields: move the SpanCollector creation, genesis
deserialization, ChainSpecBuilder, MockEthProvider setup (including
provider.add_header), genesis_header/hash,
EvolvePayloadBuilderConfig/EvolveEvmConfig/EvolvePayloadBuilder instantiation
and EvolveEnginePayloadBuilder construction into the helper and return the
needed values (SpanCollector and its guard, EvolveEnginePayloadBuilder,
genesis_hash, genesis_header); then replace the duplicated block in both tests
with a call to create_test_engine_builder and use the returned symbols when
building payloads and assertions (match names like SpanCollector,
EvolveEnginePayloadBuilder, genesis_hash, genesis_header, payload_config).
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
crates/node/src/builder.rscrates/node/src/payload_service.rscrates/node/src/txpool.rscrates/node/src/validator.rs
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/node/src/txpool.rs
randygrok
approved these changes
Mar 3, 2026
Contributor
randygrok
left a comment
randygrok
left a comment
There was a problem hiding this comment.
only pending merge conflicts
…g-spans # Conflicts: # crates/node/src/txpool.rs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Follow up to #137
Adding additional spans.
Type of Change
Related Issues
Fixes #(issue)
Checklist
Testing
Additional Notes
Summary by CodeRabbit
Chores
Tests